LineeGuidaUML ModelliArchitetturali

Copyright Adriano Comai 2002. Sono permessi lutilizzo e la distribuzione di questo documento.
LINEE GUIDA - UML - MODELLI ARCHITETTURALI

Adriano Comai 2002
Versione 1.0 del 25-1-2002
www.analisi-disegno.com
Pagina 1 di 21
INDICE
1. PREMESSA................................................................................................................................................. 3
2. ARCHITETTURA...................................................................................................................................... 3
2.1 Cosa comprende ............................................................................................................................................ 3
2.2 Sistemi e modelli ........................................................................................................................................... 4
2.2.1. Sistemi e modelli in UML ...................................................................................................................... 4
2.2.2. Modelli e diagrammi UML .................................................................................................................... 5
2.3 Documentazione dell'architettura .................................................................................................................. 5
3. MODELLI ARCHITETTURALI ............................................................................................................. 7
3.1 Modelli di analisi e di disegno....................................................................................................................... 7
3.1.1. Modello di analisi ................................................................................................................................... 7
3.1.2. Modello di disegno ................................................................................................................................. 7
3.1.3. Relazione tra i modelli di analisi e disegno............................................................................................ 7
3.1.4. Organizzazione dei modelli di analisi e disegno .................................................................................... 8
3.1.5. Specificit del modello di disegno ......................................................................................................... 9
3.2 Modello di implementazione ....................................................................................................................... 10
3.2.1. Caratteristiche generali......................................................................................................................... 10
3.2.2. Relazione con il modello di disegno .................................................................................................... 10
3.2.3. Classi e componenti.............................................................................................................................. 10
3.2.4. Componenti e Subsystems.................................................................................................................... 11
3.2.5. Organizzazione del modello ................................................................................................................. 11
4. ELEMENTI BASE DEI MODELLI ARCHITETTURALI ................................................................. 12
4.1 Classificatori ................................................................................................................................................ 12
4.1.1. Classe.................................................................................................................................................... 12
4.1.2. Interfaccia............................................................................................................................................. 12
4.1.3. Subsystem............................................................................................................................................. 13
4.1.4. Componente.......................................................................................................................................... 14
4.1.5. Nodo ..................................................................................................................................................... 15
4.2 Relazioni tra classificatori ........................................................................................................................... 16
4.2.1. Associazione......................................................................................................................................... 16
4.2.2. Dipendenza........................................................................................................................................... 17
4.2.3. Generalizzazione .................................................................................................................................. 18
5. DIAGRAMMI ........................................................................................................................................... 19
5.1.1.
5.1.2.
5.1.3.
5.1.4.
5.1.5.
5.1.6.
Diagramma delle classi......................................................................................................................... 19

Diagramma dei componenti ................................................................................................................. 20
Diagramma di distribuzione (deployment)........................................................................................... 20
Diagrammi di interazione (sequenza, collaborazione) ......................................................................... 20
Diagramma di stato .............................................................................................................................. 21
Diagramma di attivit ........................................................................................................................... 21
Pagina 2 di 21
1. Premessa
Le linee guida UML hanno un duplice obiettivo:
1. introdurre il lettore che non conosca UML al suo utilizzo. Non presuppongono conoscenze preliminari.
2. costituire, per chi abbia gi una certa conoscenza del linguaggio, un riferimento per quanto riguarda la
semantica e la notazione da utilizzare nei diagrammi.
Le linee guida fanno esclusivamente riferimento alla documentazione ufficiale di UML (nella corrente edizione,
alla versione 1.4), ed alla esperienza maturata nellutilizzo del linguaggio in ambiti applicativi eterogenei.
Non tengono assolutamente in considerazione, invece, le caratteristiche e le peculiarit dei diversi strumenti di
visual modeling UML. Di fatto, parecchi dei costrutti sintattici validi in UML, e riportati in questa linea guida, non
sono supportati da alcuni strumenti; al contrario, alcuni strumenti permettono costrutti sintattici non validi in UML.
2. Architettura
2.1 Cosa comprende
La documentazione dell'architettura di un sistema software deve descrivere come fatto internamente il sistema.
Pi in particolare, deve specificarne:
1. L'organizzazione interna in "parti" distinte, e le modalit con cui tali "parti" interagiscono tra loro per
fornire le funzionalit complessive di utilizzo del sistema (i casi d'uso)
2. Le tecnologie software utilizzate per l'implementazione e l'esecuzione delle "parti"
3. Le risorse hardware utilizzate per l'esecuzione.
L'architettura del sistema deve soddisfare i requisiti concordati per il progetto, funzionali e non funzionali (livello
di servizio, economici, temporali, ecc.). L'architettura, inoltre, contribuisce in modo essenziale a determinare i costi
del sistema, sia in termini di sviluppo che di gestione.
L'architettura, invece, non descrive come il sistema pu essere utilizzato, n i requisiti che soddisfa. Questi aspetti
sono descritti in altri documenti / modelli, spesso sotto forma di casi d'uso (si veda a tale proposito la Linea Guida
al Modello dei casi d'uso).
Architettura
<<model>>
<<model>>
<<model>>
analisi
disegno
casi duso
<<model>>
implementazione
Nota: Nel Rational Unified Process (RUP), il Software Architecture Document comprende una sezione denominata
Use-Case View, che riporta i casi d'uso del sistema pi significativi per la determinazione dell'architettura. Si tratta
di un estratto del modello dei casi d'uso, il cui ruolo nel contesto del documento di Software Architecture di
riferimento per la motivazione delle scelte architetturali, descritte nelle sezioni successive.
In questa Linea Guida, il modello dei casi d'uso non trattato, e per le sue caratteristiche si rimanda, come gi
detto, alla Linea Guida specifica.
Pagina 3 di 21
2.2 Sistemi e modelli
Un modello un'astrazione di un sistema fisico, che lo descrive in modo completo secondo uno specifico punto di
vista. Sulla base di tale punto di vista, il modello mette in evidenza alcune caratteristiche del sistema,
tralasciandone altre non rilevanti.
Per il medesimo sistema fisico possono essere definiti pi modelli complementari, ad esempio un modello dei casi
d'uso, uno di analisi, uno di disegno, uno di implementazione, uno di deployment.
E' necessario comunque operare una distinzione tra il sistema fisico che deve essere descritto e l'elemento che lo
rappresenta in un modello.
Un esempio di sistema fisico un servizio di carte di credito, che include software, hardware ed esseri umani (che
svolgono attivit inerenti il sistema). Il sistema fisico pu essere rappresentato in un modello da un sottosistema
(subsystem) di livello globale, il quale pu essere a sua volta scomposto in sottosistemi di livello inferiore. Cos,
il sottosistema "servizio carte di credito" pu essere scomposto nei sottosistemi "autorizzazione", "gestione del
credito" e "fatturazione".
2.2.1. Sistemi e modelli in UML

In UML, il Modello (Model) e il Sottosistema (Subsystem) sono dei tipi particolari di Package.
Il Package, in UML, un contenitore generico di altri elementi (come una cartella in un qualsiasi sistema operativo:
definisce un ambito di denominazione univoco (Namespace), e pu anche contenere altri package, formando in
questo modo un percorso gerarchico).
Package1
Prodotto
Package2
Prodotto
Package 3
Ordine
Magazzino
Il Modello comprende gli elementi che costituiscono una vista di un sistema (es. Use Case Model, Analysis Model,
Design Model). La rappresentazione UML ha licona base del package, con nome stereotipo <<model>>, e come
icona stereotipo un triangolo.
Il Subsystem costituisce una parte di un sistema fisico. In una gerarchia di Subsystems, il Subsystem di livello
superiore rappresenta il sistema visto nella sua globalit. La rappresentazione UML ha licona base del package,
con nome stereotipo <<subsystem>>, e come icona stereotipo un forcone.
<<Subsystem>>
FrontEnd
<<Model>>
UseCase Model
Pagina 4 di 21
Modelli e sottosistemi possono essere combinati in varie forme di gerarchia di contenimento:
Ad esempio, il sistema complessivo Servizio carte di credito pu essere rappresentato con un package di tipo
<<subsystem>>, che comprende una serie di package di tipo <<model>> (es. Casi duso, Analisi, Disegno,
Implementazione, ecc.). Ciascun Model pu quindi essere ulteriormente articolato in Subsystem (es. Front End,
Business Logic, Data Layer).
2.2.2. Modelli e diagrammi UML

Ogni modello contiene degli elementi (es. classi, casi duso, componenti), e pu comprendere (non
necessariamente) dei diagrammi. I diagrammi consentono di rappresentare in forma visuale un insieme di elementi
e di relazioni tra elementi.
Occorre sottolineare che la scelta di quanti e quali diagrammi inserire in un modello non vincolata in UML, nel
senso che il linguaggio non fornisce alcuna indicazione in merito. Il progettista, a seconda del processo di sviluppo
seguito (e degli eventuali standard presenti nella sua organizzazione) pu scegliere liberamente se e quali
diagrammi utilizzare in ogni modello.
2.3 Documentazione dell'architettura

Larchitettura, si detto, descrive come fatto internamente il sistema. Ma perch documentarla? Non
sufficiente guardare il codice applicativo, per capire com organizzato? In alcuni casi s, almeno per sistemi molto,
molto, molto semplici. Ed esistono approcci metodologici, come ad esempio eXtreme Programming, che riducono
a zero o quasi la documentazione architetturale.
Documentare larchitettura, per, pu essere vantaggioso:
pi semplice entrare in unapplicazione esistente utilizzando dei modelli sintetici (se aggiornati)
piuttosto che guardando al codice; e ci vale sia quando devo studiare unapplicazione realizzata da altri,
che quando devo rimettere le mani su una che ho realizzato io stesso in passato
pu agevolare la comunicazione tra le diverse persone e funzioni coinvolte allinterno di un progetto,
particolarmente quando le persone si trovano in ubicazioni diverse, o quando interverranno nel progetto in
momenti successivi.
E pu non essere troppo oneroso, se si utilizzano strumenti di documentazione automatica (modellazione visuale)
basati su UML. Tali strumenti sono in grado di documentare le scelte degli sviluppatori in sede di progettazione, e
di ricostruire (reverse engineering) almeno alcuni diagrammi di base (classi, sequenza) a partire dal codice
applicativo esistente.
Pagina 5 di 21
La documentazione dell'architettura di un sistema pu essere effettuata mediante una serie di modelli:
modello di analisi - descrive l'organizzazione interna del sistema ad un livello astratto, indipendente dalle
scelte tecnologiche elementi base: classi, subsystem;
modello di disegno - descrive l'organizzazione interna del sistema ad un livello che tiene conto delle
specifiche tecnologie software utilizzate per l'implementazione delle "parti" e per la loro interazione
elementi base: classi, subsystem;
modello di implementazione - descrive la configurazione delle risorse hardware necessarie per
l'esecuzione del sistema, e l'organizzazione interna del sistema a livello di componenti implementativi
(eseguibili, file, ecc.), con evidenza delle dipendenze che esistono tra tali componenti - elementi base: nodi,
componenti.
Nel Rational Unified Process, i modelli di analisi e disegno definiscono la logical view dell'architettura del sistema.
Il modello di implementazione articolato in una serie di view distinte: implementation view (componenti),
deployment view (distribuzione), process view (sincronizzazione task concorrenti).
Pagina 6 di 21
3. Modelli architetturali
3.1 Modelli di analisi e di disegno
3.1.1. Modello di analisi
Il modello di analisi rappresenta, sotto forma di classi, le "parti" fondamentali del sistema, le loro specifiche
responsabilit, le loro associazioni e le loro interazioni.
Essendo un modello indipendente dalla tecnologia di implementazione, consente di definire astrazioni stabili, e di
specificare le loro associazioni ad un livello puramente logico.
L'input principale costituito dal modello dei casi d'uso, che viene analizzato per scoprire quali parti del sistema
serviranno ad implementare le singole modalit di utilizzo, e quale ruolo dovranno svolgere in tale ambito.
Il modello di analisi contiene descrizioni statiche e dinamiche dell'organizzazione del sistema:
gli aspetti statici sono descritti sotto forma di uno o pi diagrammi delle classi;
gli aspetti dinamici sotto forma di un insieme di diagrammi di interazione e di stato.
3.1.2. Modello di disegno

Il modello di disegno descrive l'organizzazione interna del sistema ad un livello che tiene conto delle specifiche
tecnologie software utilizzate per l'implementazione delle "parti" e per la loro interazione.
La differenza sostanziale tra il modello di analisi e quello di disegno sta nel fatto che questultimo legato ad una
specifica tecnologia di implementazione (es. linguaggio), mentre il primo indipendente da caratteristiche
implementative.
Da questa prima differenza ne discendono altre due:
1. Il modello di disegno pi vincolato rispetto al modello di analisi. Deve cio conformarsi alle
caratteristiche specifiche della tecnologia di implementazione scelta: se ad esempio il linguaggio non
permette ereditariet multipla, il modello di disegno non potr prevederla.
2. Il modello di disegno generalmente molto pi complesso del modello di analisi. Rappresentando nel
dettaglio il sistema sotto un profilo maggiormente tecnico, il numero delle classi normalmente superiore,
ed aumenta di conseguenza anche la complessit dei diagrammi di interazione.
Se si utilizza uno strumento di modellazione visuale UML, il modello di disegno costituisce il punto di partenza per
la generazione del codice, ed il punto di arrivo per le attivit di reverse engineering di codice applicativo esistente.
3.1.3. Relazione tra i modelli di analisi e disegno

Il modello di analisi non costituisce necessariamente un documento separato. Nella maggioranza dei casi
costituisce solo uno "stadio preliminare" del modello di disegno, e non viene mantenuto come modello separato.
Mantenere aggiornati entrambi i modelli ha un costo, che pu risultare elevato nel corso dell'evoluzione di un
progetto e della vita del sistema. Lallineamento bi-direzionale tra modello di analisi e modello di disegno, infatti,
non automatizzabile, e va effettuato manualmente.
In alcuni casi, per, pu essere opportuno che il modello di analisi venga mantenuto come modello distinto,
separato da quello di disegno, nonostante i costi che il loro allineamento potr comportare. Ci vale in particolare
quando:
a) a fronte di un unico modello di analisi debbano essere definite implementazioni multiple, in tecnologie
diverse (e quindi vi siano diversi modelli di disegno);
Pagina 7 di 21
b) il modello di disegno risulti particolarmente complesso, e sia opportuno mantenerne una versione pi
sintetica, riportante solo le astrazioni fondamentali, in un modello di analisi.
3.1.4. Organizzazione dei modelli di analisi e disegno

Un modello di analisi o di disegno molto semplice pu essere costituito semplicemente, a livello statico, da un
insieme di classi e di associazioni.
Se il modello di analisi o disegno da realizzare complesso (indicativamente, pi di 15 o 20 classi), diventa
necessaria una qualche forma di aggregazione / raggruppamento, cio il package o, ancor meglio, il Subsystem.
Il Package, in UML, un contenitore generico di altri elementi; una tipologia particolare di Package il
Subsystem, che per al tempo stesso un tipo particolare di classificatore. Sia i package che i subsystem possono
contenere classi e associazioni.
Le classi corrispondono alle unit elementari di progettazione e realizzazione del sistema. Ogni classe svolge
determinate operazioni, gestisce certi attributi e offre una serie di servizi (eventualmente rappresentabili in modo
separato come interfacce, realizzabili da una o pi classi).
Le associazioni tra classi rappresentano meccanismi e vincoli che regolano i legami tra oggetti di classi diverse.
Il diagramma utilizzabile , naturalmente, il diagramma delle classi.
La parte dinamica dei modelli di analisi e disegno costituita dai diagrammi di stato e dai diagrammi di
interazione.
Il ciclo di vita di ogni classe pu essere rappresentato in un diagramma di stato. Il diagramma rappresenta le
condizioni (stati) in cui un oggetto della classe si pu trovare nel corso della sua esistenza, e i cambiamenti
(transizioni) tra queste condizioni che si possono verificare a fronte di determinati eventi. Non tutte le classi
necessitano di un diagramma di stato: solo quelle che presentano un ciclo di vita complesso, e che contengono
oggetti che possono trovarsi in condizioni (stati) ben distinti.
Linterazione tra classi ci che, sotto laspetto dinamico, realizza un caso duso. Pu essere rappresentata in due
diagrammi, simili per contenuto anche se diversi nella forma: il diagramma di sequenza ed il diagramma di
collaborazione. Entrambi rappresentano un insieme di classificatori (il classificatore unastrazione del concetto di
classe), o di istanze, e lo scambio dei messaggi (richieste) che questi elementi si indirizzano nellambito
dellesecuzione del caso duso.
Per ogni caso duso possono essere creati uno o pi diagrammi di interazione (idealmente, uno per ogni scenario).
Se il modello particolarmente complesso (es. numero di classi molto elevato), possibile utilizzare il subsystem
(aggregazione di classi) come elemento per la documentazione degli aspetti dinamici del sistema, definendo quindi
diagrammi di stato e di interazione che utilizzino i subsystems anzich le classi.
Naturalmente, diagrammi di interazione e di stato a livelli di subsystem forniscono semplicemente una visione
aggregata (sintetica) del comportamento dinamico delle parti del sistema. Se si desidera descrivere la dinamica ad
un livello di maggiore dettaglio, necessario utilizzare le classi.
Nota: alcuni strumenti UML non consentono di utilizzare i subsystems nei diagrammi di interazione (a differenza
con quanto previsto nello standard UML). Una possibilit di ovviare a tale limitazione consiste nel definire una
classe fittizia per ogni subsystem, contrassegnando con chiarezza (ad esempio con uno stereotipo) il fatto che tali
classi sono definite unicamente per rappresentare i subsystems.
Pagina 8 di 21
3.1.5. Specificit del modello di disegno
In termini generali, per lorganizzazione del modello di disegno valgono le medesime considerazioni fatte per il
modello di analisi. Verranno riportate qui solo alcune osservazioni supplementari.
Corrispondenza con leventuale modello di analisi.
Poich il numero delle classi nel modello di disegno tipicamente superiore a quello del modello di analisi (se il
modello di analisi viene mantenuto separatamente) una strategia possibile per mantenere la corrispondenza tra i
due modelli consiste nellassociare, ad ogni classe di analisi, un subsystem di disegno.
Bisogna per sottolineare che lorganizzazione del modello di disegno in subsystem deve essere funzionale alla
progettazione dellapplicazione, e pu essere influenzata in modo significativo anche da considerazioni di natura
implementativa legate alle tecnologie utilizzate. Tali considerazioni possono portare ad una organizzazione in
sottosistemi diversa da quella necessaria per mantenere la corrispondenza con il modello di analisi, ed hanno
comunque un peso superiore nelleconomia complessiva del progetto.
Modello dati.
A livello di modello di disegno pu essere necessario definire un modello separato relativo ai dati persistenti
che il sistema dovr gestire, implementati ad esempio in un file system o in un DBMS relazionale. Il modello
dei dati pu essere rappresentato, in termini di notazione UML, con un diagramma delle classi (ben distinto,
per, da quello che rappresenta le classi vere e proprie).
Diagrammi di stato
Come si detto, il numero delle classi contenute nel modello di disegno superiore a quello del modello di
analisi. In termini generali, per, si pu affermare che raramente, per le classi introdotte a livello di disegno,
necessaria la creazione di un nuovo diagramma di stato.
Diagrammi di interazione
Pu essere invece opportuno, per specificare meglio le responsabilit delle classi a livello tecnico, riprendere i
diagrammi di interazione (sequenza e collaborazione) realizzati in analisi, che potranno variare anche in modo
significativo per effetto delle nuove classi introdotte, con una diversa distribuzione delle responsabilit.
Pagina 9 di 21
3.2 Modello di implementazione

3.2.1. Caratteristiche generali
Descrive l'organizzazione interna del sistema a livello di componenti implementativi (eseguibili, file, ecc.), ed
evidenzia le dipendenze che esistono tra tali componenti.
Comprende sia i componenti rilasciabili (es. eseguibili) che i componenti intermedi (es. sorgenti) necessari per
produrre i componenti rilasciabili.
Il modello di implementazione comprende anche la descrizione delle risorse hardware del sistema (nodi), e delle
connessioni tra tali risorse.
E quindi possibile specificare i componenti che verranno distribuiti sui singoli nodi, ed i processi in esecuzione su
ciascun nodo.
3.2.2. Relazione con il modello di disegno

Lorganizzazione del modello di implementazione pu divergere da quella del modello di disegno, per motivi
implementative o relativi alla distribuzione dei componenti sulle risorse hardware.
In termini generali, ogni componente pu corrispondere ad una aggregazione di classi, e quindi anche ad un
sottosistema (che a sua volta non altro che unaggregazione di classi).
Una prassi molto diffusa di stabilire inizialmente una corrispondenza uno a uno tra i subsystems del modello di
disegno ed i componenti del modello di implementazione.
Questa corrispondenza iniziale pu essere variata, come accennato, per effetto di diverse considerazioni:
strutturazione in layers (strati) del modello di implementazione, divers da quella prevista nel modello di
disegno
riduzione e/o semplificazione delle dipendenze tra componenti (ottenuta, ad esempio, creando un nuovo
package di componenti riusabili)
presenza di componenti legacy con i quali necessario interagire
gestione della configurazione del sistema, anche in considerazione dellorganizzazione di progetto in
gruppi distinti
considerazioni relative al deployment dei componenti sulle risorse hardware (nodi)
3.2.3. Classi e componenti

Per sistemi realizzati con tecnologie object oriented, le caratteristiche del componente sono definite dai
classificatori che risiedono (<<reside>>) nel componente. I componenti realizzati con altre tecnologie
corrispondono a programmi, moduli, ...
Ordine
<<reside>>
Ordine
<<reside>>
Ordine
RigaOrdine
Ordine
RigaOrdine
Pagina 10 di 21
In UML, la corrispondenza tra componenti e classi pu essere espressa in due modi:
a) includendo le icone delle classi allinterno dellicona del componente in cui risiedono, oppure
b) con una dipendenza che va dal componente alla classe, con stereotipo <<reside>>.
Per componenti non realizzati con tecnologie object oriented, naturalmente, la corrispondenza con le classi non
necessaria.
3.2.4. Componenti e Subsystems

In UML, la corrispondenza definibile tra subsystem e componente <<refine>>, raffinamento, nel senso che un
componente, nel modello di implementazione, raffina un sottosistema presente nel modello di disegno.
Questa corrispondenza favorita dal fatto che possibile definire componenti composti da altri componenti,
esattamente come un subsystem pu essere composto da altri subsystems. In altri termini, possibile definire
gerarchie di componenti, che corrispondono a livello implementativo alle gerarchie di subsystems.
Inoltre, sia il subsystem che il componente, a livelli diversi, in ambito object oriented non sono altro che
aggregazioni di classi.
3.2.5. Organizzazione del modello

Il modello di implementazione sfrutta i due diagrammi di implementazione previsti da UML: il diagramma dei
componenti ed il diagramma di distribuzione (deployment).
Il diagramma dei componenti rappresenta visivamente i componenti, le interfacce e le dipendenze che li legano.
Il diagramma di deployment mostra la configurazione delle risorse hardware del sistema, sotto forma di nodi e di
connessioni tra nodi, ed eventualmente i componenti, oggetti e processi (task) allocati in tali nodi.
Pagina 11 di 21
4. Elementi base dei modelli architetturali
4.1 Classificatori
Il classificatore (classifier), nel meta-modello di UML, un elemento che descrive aspetti strutturali e
comportamentali.
In termini generali, un classificatore pu:
avere attributi ed operazioni
avere istanze proprie
avere associazioni con altri classificatori
essere specializzato
Tipologie particolari di classificatore (e limiti specifici):
classe (class)
tipo (type: pu dichiarare operazioni, ma non pu implementarle con un metodo; non pu essere
istanziato; in alcuni approcci metodologici, sostituisce lelemento classe nel modello di analisi)
interfaccia (interface: pu dichiarare operazioni, ma non pu implementarle con un metodo; non pu
essere istanziata in modo diretto; non pu avere attributi)
attore (actor: pu essere associato solo a casi duso, subsystems, classi, interfacce)
caso duso (use case: pu avere associazioni solo con attori e interfacce)
componente (component: non pu avere attributi e operazioni; non pu avere associazioni; non pu
essere specializzato)
nodo (node: non pu essere specializzato)
subsystem (non pu avere attributi propri; pu dichiarare operazioni, ma non pu implementarle in modo
diretto)
segnale (signal)
artifact
...
nome
elenco attributi
elenco operazioni
Licona di base per la rappresentazione di un classificatore un rettangolo con tre comparti: nome, elenco degli
attributi, elenco delle operazioni.
4.1.1. Classe
E un classificatore che rappresenta una parte del sistema, dotata di caratteristiche (attributi) e comportamenti
(operazioni).
Pi propriamente, la classe definisce gli attributi, le operazioni e le associazioni che caratterizzano e si applicano ad
un insieme di oggetti, che costituiscono le istanze della classe. Ogni oggetto della classe (o di sottoclassi della
classe) pu avere valori specifici per ogni attributo definito nella classe (variabili di istanza); ad esso si applicano
tutte le operazioni dichiarate nella classe.
Fanno eccezione attributi ed operazioni il cui scope (ambito) la classe stessa: i primi con costituiscono variabili
di istanza, e non vengono quindi valorizzati sui singoli oggetti; le seconde non vengono indirizzate ad oggetti
specifici, bens alla classe nella sua globalit.
La classe pu essere associata ad altre classi, e implementare un insieme di interfacce.
La classe costituisce lelemento base dei modelli di analisi e di disegno.
4.1.2. Interfaccia
Pagina 12 di 21
E un classificatore che dichiara un insieme di operazioni, ma non le pu implementare con metodi.
Costituisce un meccanismo fondamentale per il disaccoppiamento (decoupling) tra le diverse parti del sistema,
consentendo a chi richiede una operazione di indirizzare messaggi generici, senza preoccuparsi delle particolarit
implementative di chi fornir il relativo servizio.
Ad esempio, un componente elaboratore di testi pu richiedere servizi di stampa a stampanti diverse, ma
formulando le richieste (stampa, annulla stampa, sospendi, riprendi) sempre con le stesse modalit, dichiarate in
una interfaccia comune.
Gestore
Documenti
<<Interface>>
Stampante
+ stampa()
+ sospendi()
+ annulla()
+ riprendi()
Driver
StampanteX
Driver
StampanteY
Le interfacce possono essere associate con gli elementi che le implementano, cio che offrono i servizi dichiarati
dalle operazioni dellinterfaccia. Ogni interfaccia pu essere implementata da diversi elementi.
Pi in particolare, possono implementare interfacce, nei modelli di analisi e disegno, i seguenti classificatori:
attori
classi
subsystem
Nel modello di implementazione, le interfacce possono essere implementate da componenti.
Licona specifica per rappresentare uninterfaccia un cerchio bianco, collegato agli elementi che implementano
linterfaccia da una linea continua.
Gestore
Documenti
Stampante
Driver
Stampante 1
Driver
Stampante2
La relazione tra il client (chi richiama le operazioni definite nellinterfaccia) e linterfaccia invece rappresentata
con una dipendenza (linea tratteggiata, punta della freccia aperta).
4.1.3. Subsystem
Il Subsystem una tipologia particolare di Package, e al tempo stesso un tipo particolare di classificatore.
Questa duplicit lo rende un costrutto estremamente versatile e potente per modellare e organizzare applicazioni
complesse, costituite da numerose classi.
In quanto tipo particolare di Package, il Subsystem pu contenere altri elementi, ed esattamente: Package, Classi,
DataTypes, Interfacce, Casi duso, Attori, Subsystems, Segnali, Associazioni, Generalizzazioni, Dipendenze,
Vincoli, Collaborazioni, Macchine di Stato, Stereotipi.
Sempre in quanto tipo particolare di Package, il Subsystem pu accedere al contenuto di altri Subsystem, oppure
importarlo.
Pagina 13 di 21
Tra package (e quindi tra subsystems) possono essere infatti definite dipendenze. Le tipologie specifiche di
dipendenze ammesse tra package sono <<access>> (visibilit sugli elementi pubblici contenuti nel package
destinatario) e <<import>> (copia all'interno del package di una versione degli elementi pubblici contenuti nel
package destinatario).
Package3
<<access>>
Package4
Package1
<<import>>
Package2
In quanto tipo particolare di Classificatore, il Subsystem pu essere istanziato (possono cio esistere diverse istanze
di un medesimo Subsystem nellambito dello stesso sistema fisico). Inoltre, il Subsystem pu essere associato ad
altri Subsystem, e specializzare altri Subsystem.
Il Subsystem non pu definire attributi, pu per definire operazioni, e realizzare interfacce, che rappresentano i
servizi offerti dal subsystem nella sua globalit. Il Subsystem non ha, infatti, un comportamento proprio: il suo
comportamento deriva da quello dei classificatori in esso contenuti, e sono quindi tali classificatori a realizzare le
operazioni ed offrire i servizi dellinterfaccia.
Nella definizione di un subsystem, cos come nella sua rappresentazione grafica, vengono distinti gli elementi di
specifica e gli elementi di realizzazione. Gli elementi di specifica possono essere casi duso, interfacce, operazioni.
Gli elementi di realizzazione sono costituiti tipicamente da classi, o, per maggiore precisione, da collaborazioni di
classi, le cui istanze, interagendo, implementano i servizi descritti dagli elementi di specifica del subsystem.
4.1.4. Componente
Rappresenta una parte del sistema, modulare, distribuibile e sostituibile, che incapsula gli aspetti implementativi ed
espone un insieme di interfacce.
Le caratteristiche ed il comportamento di un componente sono specificati dai classificatori che risiedono nel
componente, in modo particolare interfacce e classi. Le interfacce specificano i servizi offerti dal componente,
mentre le classi ne specificano limplementazione.
Pagina 14 di 21
Un componente pu essere implementato in pi artifact (es. sorgenti, eseguibili). Lartifact un elemento

aggiunto a UML nella versione 1.4, per rappresentare gli elaborati fisici (es. documenti) prodotti dalle diverse
attivit progettuali.
Ordine
<<jarfile>>
Ordine
<<implement>>
Un componente pu essere distribuito (deployed) su un nodo.
:Client
<<browser>>
:OpenSourceBrowser
Un componente pu essere composto da altri componenti

<<application>>
VideoStoreApplication
<<session>>
ShoppingSession
<<entity>>
Catalog
<<entity>>
ShoppingCart
4.1.5. Nodo
Il nodo un oggetto fisico presente nellambiente di esecuzione, dotato in genere di memoria e di capacit di
elaborazione, sul quale possono essere ubicati dei componenti e degli oggetti.
Sono tipicamente rappresentati come nodi i computer su cui viene eseguito un sistema software; a livello di
Business Modeling, per, possono essere rappresentati come nodi anche esseri umani o unit organizzative (in
questo caso, possono essere rappresentati come componenti le procedure e i documenti trattati dallessere umano o
dallunit organizzativa).
I nodi possono essere connessi da associazioni, che indicano un percorso di comunicazione.
Licona per rappresentare un nodo il parallelepipedo.
Pagina 15 di 21
4.2 Relazioni tra classificatori

La relazione (relationship) semplicemente una connessione tra elementi UML. Esempi particolari di relazione
sono lassociazione, la dipendenza e la generalizzazione.
4.2.1. Associazione
Lassociazione (association) dichiara una relazione semantica tra classificatori, e rappresenta un insieme di
legami (link) tra le istanze di tali classificatori.
Ogni associazione ha almeno due estremi (association ends), per ognuno dei quali possono essere definiti:
un nome
una molteplicit
un indicatore di navigabilit
Il nome degli estremi delle associazioni che partono da un classificatore deve essere univoco, anche rispetto agli
eventuali attributi del classificatore.
La molteplicit indica il numero di istanze del classificatore associato ad un estremo che possono essere collegate a
ciascuna delle istanze del classificatore collocato allaltro estremo dellassociazione, ed espressa sotto forma di
range di interi non negativi.
Cliente
Ordine
1
0..*
Lindicatore di navigabilit indica se possibile raggiungere le istanze collocate ad un estremo a partire da una
istanza collocata allaltro estremo dellassociazione.
password
User
1
Password
Le associazioni possono essere di tre tipi:

normali
aggregazioni (semplici)
aggregazioni di composizione
Le aggregazioni semplici (aggregation) esprimono una relazione tra un insieme e delle parti di tale insieme
(tutto / parte), ma non implicano vincoli particolari per lesistenza della parte o dellinsieme.
Sono espresse con una losanga bianca, collocata allestremo dellassociazione vicino al classificatore che
rappresenta linsieme.
Comitato
Persona
*
Le aggregazioni di composizione (o pi semplicemente, composizioni composition) implicano vincoli precisi:

ogni istanza del classificatore parte pu essere riferita ad una sola istanza del tutto; inoltre, il tutto
responsabile per la creazione e la distruzione delle sue parti, che non possono avere una esistenza autonoma.
Pagina 16 di 21
Sono espresse con una losanga nera, collocata allestremo dellassociazione vicino al classificatore che rappresenta
linsieme.
Ordine
RigaOrdine
1
1..*
4.2.2. Dipendenza
La dipendenza (dependency) una relazione semantica tra elementi di modello (non necessariamente
classificatori). Indica che il funzionamento di un elemento (ad esempio un componente) richiede la presenza di uno
o pi altri elementi (ad esempio di un altro componente).
La dipendenza implica che, se un elemento viene modificato, potrebbe essere necessario modificare anche ogni
elemento che da esso dipende (nellesempio, se viene modificata la classe B possibile che debba essere
modificata anche la classe A).
A
A differenza della associazione, che comporta lesistenza di legami a livello di istanze, la dipendenza collega
direttamente gli elementi di modello, e non comporta n necessita lesistenza di istanze.
La dipendenza espressa con una freccia tratteggiata, che parte dallelemento client (dipendente) e arriva
allelemento supplier (quello necessario per il funzionamento del client).
UML prevede diversi stereotipi standard di dipendenza, tra cui :
Steretipo
access
bind
derive
import
refine
trace
Significato
Indica il permesso per un package di referenziare gli elementi pubblici contenuti in un altro package
Lassegnazione di valori ai parametri di una template per creare un elemento a partire da essa
Indica un algoritmo di derivazione di un (insieme di) elemento a partire da un altro (insieme di)
elemento
Indica il permesso per un package di importare gli elementi pubblici contenuti in un altro package
Indica una relazione di derivazione tra due elementi (es. un caso duso system da un caso duso
business)
Connessione tra due elementi che rappresenta lo stesso concetto a livelli diversi di significato (es. tra
richieste degli stakeholder e software requirements)
Pagina 17 di 21
4.2.3. Generalizzazione
La generalizzazione (generalization) una relazione che collega un elemento pi generico ad un elemento pi
specifico.
Lelemento pi specifico deve essere pienamente consistente con quello pi generico, cio ne eredita tutte le
caratteristiche (ad esempio una sottoclasse eredita tutti gli attributi, le operazioni e le associazioni delle sue
superclassi), ma pu definire ulteriori attributi, operazioni e relazioni.
La generalizzazione una relazione che definisce dei sottotipi: un istanza dellelemento generico pu essere
sempre sostituita da unistanza dellelemento pi specifico.
A
La generalizzazione espressa con una linea continua, conclusa con una punta di freccia chiusa allestremo
corrispondente allelemento generico.
Pagina 18 di 21
5. Diagrammi
Vengono esposte di seguito alcune caratteristiche dei diagrammi UML che hanno rilevanza dal punto di vista
architetturale, cio che possono essere utilizzati per rappresentare lorganizzazione interna del sistema.
Non verr quindi trattato il diagramma dei casi duso, che rappresenta le modalit di utilizzo del sistema, per il
quale si rimanda alla Linea Guida al Modello dei casi d'uso.
UML prevede due grandi famiglie di diagrammi architetturali: i diagrammi strutturali e quelli comportamentali.
Diagrammi strutturali
Rappresentano la struttura statica del sistema: le sue parti (es. classi, interfacce, componenti, nodi); la struttura
interna di queste parti; le relazioni tra le parti.
Tipologie:
diagramma delle classi (class diagram)
diagramma dei componenti (component diagram)
diagramma di distribuzione (deployment diagram)
Gli ultimi due sono chiamati, in UML, diagrammi di implementazione (implementation diagrams).
Diagrammi comportamentali
Rappresentano gli aspetti dinamici del sistema, o delle diverse parti del sistema.
Tipologie:
diagramma di sequenza (sequence diagram)
diagramma di collaborazione (collaboration diagram)
diagramma di stato (statechart diagram)
diagramma di attivit (activity diagram)
I primi due sono chiamati, in UML, diagrammi di interazione (interaction diagrams).
5.1.1. Diagramma delle classi

Chiamato anche diagramma strutturale statico (static structural diagram), fornisce una rappresentazione
strutturale di un insieme di classificatori (o di istanze), delle loro propriet e delle relazioni che li collegano.
Si tratta di una rappresentazione statica: gli aspetti dinamici e temporali sono rappresentati in altri diagrammi
(interazione, stato, attivit).
In linea di principio, un diagramma delle classi pu rappresentare qualunque tipo di classificatore: classi, ma anche
casi duso, attori, componenti, ...
Naturalmente le caratteristiche (es. attributi, operazioni) e le relazioni (es. associazioni, dipendenze) lecite nel
diagramma sono vincolate dalla tipologia specifica dei classificatori rappresentati (ad esempio non ammesso
rappresentare in un diagramma delle classi una associazione tra componenti, in quanto i componenti possono essere
collegati solo tramite dipendenze).
Il diagramma delle classi pu rappresentare anche istanze (oggetti). Un diagramma che contenga solo istanze di
classi e associazioni riceve il nome di diagramma degli oggetti (object diagram).
Pagina 19 di 21
5.1.2. Diagramma dei componenti
Rappresenta un insieme di componenti, collegati da dipendenze, e di interfacce (implementate dai componenti). Per
ogni componente pu rappresentare, in ambito object oriented, i classificatori che risiedono nel componente.
E inoltre possibile indicare gli artifact che implementano il componente (es. la versione sorgente e la versione
eseguibile del medesimo componente costituiscono due artifact distinti).
Il diagramma pu rappresentare i componenti solo come tipi, e non come istanze. Istanze di componenti possono
essere invece rappresentate in un diagramma di distribuzione (deployment) (in quanto si presuppone che unistanza
di componente software non possa esistere se non nellambito di uno specifico nodo hardware).
5.1.3. Diagramma di distribuzione (deployment)

Rappresenta la configurazione dei nodi hardware su cui vengono eseguiti componenti, processi e oggetti, e delle
connessioni tra tali nodi.
Pu rappresentare i componenti, processi ed oggetti presenti allinterno di ciascun nodo.
Il diagramma pu rappresentare la configurazione hardware del sistema in termini generali (a livello di tipi), oppure
fotografare (a livello di istanze) una specifica situazione, in cui vengono specificate specifiche istanze di nodi,
componenti, processi ed oggetti.
5.1.4. Diagrammi di interazione (sequenza, collaborazione)

Rappresentano il modo in cui unoperazione o un caso duso vengono risolti dalla collaborazione tra un insieme di
oggetti, ed i messaggi che tali oggetti si scambiano.
Dei due diagrammi, quello di sequenza enfatizza gli aspetti temporali, ed in modo particolare lordine temporale
dei messaggi; quello di collaborazione evidenzia invece le relazioni tra gli oggetti.
I diagrammi di interazione possono essere realizzati sia a livello di tipi che di istanze. Tipi, se lintenzione quella
di rappresentare uninterazione in termini generali; istanze, se si vuole rappresentare una specifica esecuzione di
una interazione.
Gli oggetti che compaiono in un diagramma di interazione possono corrispondere in linea di principio a
qualunque classificatore, e non solo, come succede abitualmente, ad istanze di classi.
E quindi possibile creare diagrammi di interazione che specifichino gli aspetti dinamici di collaborazioni tra ruoli
organizzativi (rappresentati come attori o come workers, secondo il profilo UML per il Business Modeling); tra
componenti; tra nodi; tra subsystems (vedi figura).
4:receive
1:transmit
2:send
3:ack
Pagina 20 di 21
5.1.5. Diagramma di stato

Rappresenta il comportamento di un classificatore, mostrando le condizioni in cui si pu trovare nel corso della sua
esistenza (stati), gli eventi che lo possono interessare e le transizioni a nuovi stati.
Il diagramma riferibile tipicamente agli oggetti di una classe, ma pu anche descrivere il comportamento di altri
classificatori, quali subsystems, attori, casi duso.
5.1.6. Diagramma di attivit

E un caso speciale di diagramma di stato, in cui tutti gli stati sono stati di attivit e tutte le transizioni sono legate
al completamento delle attivit svolte nello stato di partenza.
A differenza del diagramma di stato, il diagramma di attivit si concentra maggiormente sulla definizione di flussi
elaborativi interni, e non sulla reazione ad eventi esterni.
Il diagramma riferibile tipicamente ad un caso duso, o allimplementazione di unoperazione di un classificatore.
Pagina 21 di 21

LineeGuidaUML ModelliArchitetturali

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

LineeGuidaUML ModelliArchitetturali

Caricato da

Copyright:

Formati disponibili

Copyright Adriano Comai 2002. Sono permessi lutilizzo e la distribuzione di questo documento.

LINEE GUIDA - UML - MODELLI ARCHITETTURALI

Diagramma delle classi......................................................................................................................... 19

2.2.1. Sistemi e modelli in UML

2.2.2. Modelli e diagrammi UML

2.3 Documentazione dell'architettura

3.1.2. Modello di disegno

3.1.3. Relazione tra i modelli di analisi e disegno

3.1.4. Organizzazione dei modelli di analisi e disegno

3.2 Modello di implementazione

3.2.2. Relazione con il modello di disegno

3.2.3. Classi e componenti

3.2.4. Componenti e Subsystems

3.2.5. Organizzazione del modello

Un componente pu essere implementato in pi artifact (es. sorgenti, eseguibili). Lartifact un elemento

Un componente pu essere distribuito (deployed) su un nodo.

Un componente pu essere composto da altri componenti

4.2 Relazioni tra classificatori

Le associazioni possono essere di tre tipi:

Le aggregazioni di composizione (o pi semplicemente, composizioni composition) implicano vincoli precisi:

5.1.1. Diagramma delle classi

5.1.3. Diagramma di distribuzione (deployment)

5.1.4. Diagrammi di interazione (sequenza, collaborazione)

5.1.5. Diagramma di stato

5.1.6. Diagramma di attivit

Potrebbero piacerti anche