Azzolini Riccardo 2019-12-03
Altri diagrammi UML
1 Timing diagram
I timing diagram permettono la rappresentazione esplicita del tempo. Essi sono utili per mostrare:
• come lo stato/valore di un elemento cambia nel tempo;
• l’interazione tra eventi temporizzati;
• i vincoli di tempo e di durata tra eventi temporizzati.
Questi diagrammi possono quindi essere usati per esprimere, ad esempio, i vincoli non funzionali relativi alle prestazioni.
1.1 Lifeline
Una lifeline si disegna in modo diverso a seconda del tipo di stato dell’entità rappresen- tata:
• valori discreti:
State 1 State 2 State 3 State 4
{Time Constraint}
Event {Duration Constraint}
TimeLine1
0 10 20 30 40 50 60 70 80 90 100
• valori continui:
0 2.5 1 10
{Time Constraint} Event
{Duration Constraint}
TimeLine2
0 10 20 30 40 50 60 70 80 90 100
In corrispondenza di una transizione (cambiamento di stato) è possibile indicare
• eventi
• vincoli di tempo
• vincoli di durata
che provocano tale transizione.
1.2 Lifeline multiple
Un diagramma può contenere anche due o più lifeline, che:
• devono avere tutte lo stesso asse x;
• possono scambiarsi dei messaggi (indicati tramite delle frecce), e questi possono provocare delle transizioni.
Idle WaitCard AccessWait Idle
{d..d*3}
Start
Code 0..13
OK {t..t+3}
{d..d*3}
WaitAccess WaitCard Idle
NoCard
HasCard
UserAcceptedACSystemUser
0 10 20 30 40 50 60 70 80 90 100 110 120
2 Component diagram
Un componente rappresenta una parte modulare di un sistema:
• incapsula i propri contenuti;
• il suo comportamento è definito in termini di interfacce fornite e richieste;
• di solito, è implementato da una o più classi/oggetti, ma può comprendere anche documentazione, ecc.;
• può avere più implementazioni, che sono intercambiabili: una qualsiasi di esse può essere immessa nell’ambiente di esecuzione.
Le funzionalità di un sistema si possono costruire assemblando componenti, cioè colle- gando le interfacce fornite e richieste.
Un component diagram descrive i componenti che costituiscono concretamente il sistema finale (mentre i class diagram, ecc., sono diagrammi concettuali).
2.1 Esempio
Order Customer
Product
Account Item Code
Customer Details
Account Details Payment
3 Deployment diagram
I deployment diagram specificano l’architettura del sistema, descrivendo l’assegna- mento dei semilavorati software (artifact) ai nodi hardware.
3.1 Nodi
I nodi rappresentano dispositivi hardware o ambienti di esecuzione software.
Server ServerInstance1: Server
Essi possono essere descritti come annidati, e possono essere connessi da canali di comunicazione, che consentono di modellare sistemi a rete.
3.2 Artifact
Un artifact è la specifica di un’informazione “fisica” usata o prodotta da un processo di sviluppo, o nell’installazione e uso di un sistema.
«artifact»
main.c
Alcuni esempi di tipi di artifact sono:
• file di modelli;
• file sorgenti;
• script;
• eseguibili binari;
• tabelle di un database;
• documenti tecnici;
• messaggi di email;
• ecc.
3.3 Esempio
* 1
«deploy» «deploy»
AppServer DBServer
: AppServer
«artifact»
Order.jar
«artifact»
RequestHandler.jar
3.4 Notazione alternativa
Invece di rappresentarli separatamente,
«deploy» «deploy»
: AppServer1
«artifact»
ShoppingCart.jar
«artifact»
Order.jar
gli artifact assegnati a un nodo possono essere elencati all’interno del nodo stesso:
: AppServer1 Order.jar
ShoppingCart.jar Account.jar Product.jar BackOrder.jar Service.jar
3.5 Esempio di rete
1 1
«tcp-ip»
1 1
«ethernet»
1
1..*
«ethernet»
local network firewall
primary server
workstation
