La modellizzazione di sistemi tolleranti ai guasti con Gspn e Uml e sua applicazione nel progetto Tiran

7 
Order può essere associato ad un solo Customer. In generale la molteplicità è indicata con 
n..m dove n ed m sono gli estremi inferiore e superiore possibili. 
     
 
 
  
 
Order 
dateReceived 
isPrepaid 
number: String 
price: money 
dispatch() 
close() 
creditRating():String 
Customer  
name  
address 
Association 
* 
1 
Costraint 
Attributes 
Operations 
Class 
Generalization 
Order Line 
quantity: Integer  
price: Money  
isSatisfied: Boolean 
line  
items 
* 
* 
1 
* 
Product 
{if Order.customer.creditRating is  
"poor", then Orders.isPrepaid   
must be true} 
1 
{creditRating()==  
"poor"} 
sales rep 
0..1 
Employee 
Multiplicity:  
optional 
Multiplicity:  
Many-valued 
Multiplicity:  
mandatory 
Personal  
Customer 
creditCard# 
Corporate  
Customer 
remind()  
billForMonth(integer) 
contractName  
creditRating  
creditLimit 
Fig.1.1  
 
Passiamo ora alla prospettiva descrittiva. In questa prospettiva le associazioni 
rappresentano "responsabilità"; il fatto che ci sia un'associazione tra Customer e Order 
implica che ci sia uno o più metodi in Customer che mi dicano quali Order il Customer 
ha fatto ed implica anche che ci siano dei metodi in Order che mi permettano di 
identificare quale Customer ha fatto un certo Order. Queste responsabilità non dicono 
nulla su come devono essere strutturati i dati.