Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
I corsi di Ingegneria
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Porfirio Tramontana » 9.Modellazione architetturale


Altri diagrammi strutturali

Oltre ai Class Diagram, UML 2 propone altri diagrammi che possiamo definire strutturali, in quanto modellano aspetti “statici” della struttura del sistema:

  • Object Diagram (o diagrammi degli oggetti, o delle istanze);
  • Package Diagram;
  • Component Diagram;
  • Deployment Diagram.

Object Diagram

Un object diagram rappresenta una “fotografia” di un class diagram (o di una sua parte) in un determinato istante.

In luogo di ogni classe compaiono uno o più istanze di oggetti di quella classe, identificati con la notazione nomeoggetto:nomeclasse.

Si potrebbe disegnare un diagramma degli oggetti per ogni scenario di ogni caso d’uso.

Lo scopo degli object diagram (peraltro non utilizzati molto spesso) è quello di chiarire le relazioni tra classi che possono istanziarsi in un particolare scenario d’esecuzione, mostrando, ad esempio, una specifica risoluzione di una situazione di polimorfismo.

Esempio Object Diagram


Package diagram

Un package è un contenitore di classi.
In Java il package è identificato dalla omonima keyword; in altri linguaggi esistono costrutti analoghi; In UML (e anche in Java) è possibile definire una visibilità (di classi, metodi o attributi), in termini di package, ovvero definire un elemento come visibile solo all’interno del package nel quale è dichiarato.

Un package rappresenta uno spazio dei nomi (namespace): il nome completo che identifica una classe è, quindi:
Nomepackage::nomeclasse

Suddivisione in packages

Dato un sistema software composto di molte classi, esistono un enorme quantitativo di possibili raggruppamenti delle classi in package. Quale scegliere?

  • Bisogna stabilire un principio secondo il quale operare il raggruppamento: in generale si dice che vengono raggruppate tra loro classi che presentano una buona coesione.
    • Se ne discuterà a margine della proposizione dei principi di progettazione, nelle prossime lezioni.

Generalization e implementation

Tra due packages può insistere una relazione di dependency se esiste una coppia di classi appartenenti rispettivamente ai due packages e legate da una relazione di dependency.

Allo stesso modo potrebbero essere considerate le generalizzazioni tra package oppure le relazioni tra classi concrete e classsi astratte da esse implementate.


Façade

Si consideri un package; si voglia fornire al resto del sistema la possibilità di accedere solo ad un sottoinsieme delle operazioni implementate nelle varie classi del package.

Si implementa una classe Façade che:

  • Abbia visibilità public;
  • Richiami e fornisca attributi e metodi delle classi interne al package (invisibili all’esterno del package stesso).

Considerazioni

I diagrammi dei package sono utili, nella progettazione di grandi sistemi, per poter suddividere il problema della progettazione in sottoproblemi più piccoli e semplici da governare.

I package diagram sono, in generale, dei diagrammi di architettura, per cui essi possono essere utili nelle fasi di design e di implementazione, non in quella di analisi del problema.

Component diagrams

Il concetto di componente è molto dibattuto, in UML.
Un componente è un contenitore di altri elementi statici UML, come classi e package.
Spesso, il component si identifica come un componente fisico, come ad esempio un file contenente codice sorgente, oppure un file eseguibile, o un database, …
Altre volte il concetto di component coincide con quello di package (ad esempio nelle librerie java “impacchettate” in un unico file con estensione .jar).
Nell’accezione UML 2, invece, un component può anche contenere altri component al suo interno.

Component diagrams (segue)

Il component diagram mostra insiemi di componenti e di relazioni tra loro.

Per ogni component si vuole mostrare esplicitamente l’interfaccia che esso espone all’esterno (utilizzando la notazione con lollipop).

Il diagramma dei componenti è, quindi, un diagramma architetturale che mostra oggetti effettivamente realizzati, ma che non comprende informazioni sulla effettiva dislocazione fisica di tali componenti.

Esempio di component diagram


Deployment Diagram

I diagrammi di deployment (in italiano dispiegamento) mostrano l’architettura fisica del sistema.

L’elemento fondamentale è il nodo, corrispondente ad un elemento fisico del sistema (ad esempio una macchina o un dispositivo).

All’interno dei nodi possono essere disegnati i component, in modo da poter collegare il deployment diagram ai component diagram corrispondenti.

I prodotti dell’elaborazione sono rappresentati dagli artifact.

Con il concetto di artifact si interpreta un qualsiasi oggetto fisico prodotto dal sistema.

Gli archi di un deployment diagram corrispondono alle connessioni fisiche tra i suoi nodi.

Esempio di Deployment Diagram


Deployment Diagram

I deployment diagram sono dei diagrammi architetturali che possono essere utilizzati in fase di progetto architetturale e in fase di implementazione.

Talvolta è necessario introdurli già in fase di analisi del problema qualora si voglia rappresentare vincoli architetturali posti alla base del problema.

I materiali di supporto della lezione

Martin Fowler, UML Distilled, capitoli 6 (object diagram), 7 (package diagram), 8 (deployment diagram), 13 (composite structure diagram), 14 (component diagram).

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion