Altra Tesina

Transcript

Altra Tesina
Università degli Studi di Modena e Reggio Emilia
Gestione di manifestazioni e gare
di tiro con l’arco
mediante il modello MDT
Anceschi Matteo
matr. 2098
Anno Accademico 1999-2000
Ingegneria del Software
Prof.Bonfatti Flavio
Indice
1. Specifiche di Progetto
4
1.1 Specifiche e caratteristiche……………………………………………………………….4
1.2 Funzionalità richieste…………………………………………………………………….6
2. Modello Statico
7
2.1 Discipline – Impianti – Categorie………………………………………………………...7
2.2 Federazioni – Manifestazioni – Concentramenti – Gare………………………………...13
2.3 Allenatori – Atleti – Società……………………………………………………………..17
2.4 Cartellini – Punteggi – Trofei……………………………………………………………25
3. Modello Funzionale
30
3.1 Visualizzazioni: View…………………………………………………………………...30
3.2 Inserimenti: Event……………………………………………………………………….33
3.3 Aggiornamenti: Event…………………………………………………………………...35
3.4 Eliminazioni: Event……………………………………………………………………...36
Gestione gare di tiro con l’arco
INGEGNERIA DEL SOFTWARE
Indice delle figure
2.1 Virtual e Value iniziali……………………………………………………………………...11
2.2 Discipline – Impianti – Categorie…………………………………………………………...12
2.3 Federazioni – Manifestazioni – Concentramenti – Gare……………………………………16
2.4 Allenatori – Atleti…………………………………………………………………………...23
2.5 Società………………………………………………………………………………………24
2.6 Cartellino……………………………………………………………………………………28
2.7 Trofei – Punteggi……………………………………………………………………………29
INGEGNERIA DEL SOFTWARE
Gestione gare di tiro con l’arco
1
Specifiche di Progetto
1.1 Specifiche e caratteristiche
Lo scopo di questo progetto è la descrizione delle attività che ruotano attorno agli eventi sportivi
nel tiro con l’arco, tramite l’utilizzo del modello MDT, convalidandone così la potenza
espressiva. Ciò consentirà di avere una visione, completa nei suoi tratti salienti, delle attività che
gravitano attorno a questo sport. In particolar modo ci si è soffermati sulle interconnessioni tra i
diversi elementi cercando di stabilire relazioni corrette tra tutte le entità che fanno parte di
questo settore.
In particolare, le informazioni da gestire riguardano:
Discipline – Impianti – Categorie
I partecipanti a questo sport gareggiano seguendo diverse specialità (pensiamo agli stili nel
nuoto, oppure alle diverse tipologie di confronti fra agonisti nelle gare di atletica): sono
appunto le discipline. Ognuna di esse è caratterizzata in particolare dalla distanza di tiro
nella specialità (una misura in metri multipla di 25, come da tradizione) e dalle modalità di
confronto tra i vari atleti presenti: essi possono gareggiare in un girone, oppure in un torneo,
ecc…
I partecipanti vengono inoltre suddivisi in categorie, cioè fasce che si differenziano tra loro
per l’età ed il sesso, e che ammettono in generale sia uomini che donne dai 6 agli 80 anni.
Ad ogni categoria (l’osservazione vale per entrambi i sessi) viene assegnato un nome
univoco, in modo da semplificare gli eventuali vincoli di ammissione alle varie
competizioni: a seconda dei regolamenti internazionali saranno infatti assegnate discipline
diverse a categorie differenti.
Queste competizioni si svolgono in impianti situati sul territorio e caratterizzati da un
nome, dalla lunghezza massima sfruttabile per il tiro e dal numero di partecipanti che
possono tirare contemporaneamente (le cosiddette “corsie”) il cui numero è stabilito a
livello internazionale e varia tra 4 e 50.
Gestione gare di tiro con l’arco
INGEGNERIA DEL SOFTWARE
CAPITOLO 1 – SPECIFICHE DI PROGETTO
Federazioni – Manifestazioni – Concentramenti – Gare
A livello nazionale (ma un discorso pressochè analogo può essere fatto a livello
internazionale) le entità che sovraintendono all’andamento agonistico sono le federazioni,
che possono essere identificate univocamente sia da una sigla che da un nome.
Gli eventi sportivi sono caratterizzati in generale come manifestazioni, identificate da un
codice univoco: si può pensare ad un campionato nazionale, una rassegna, un trofeo (un
caso che verrà modellato a parte) o comunque insiemi di gare che si svolgono in un certo
intervallo temporale. Possono o meno essere patrocinate da una federazione (in questo caso
vengono classificate come ufficiali), ma vengono sempre e comunque organizzate da una
società.
Data l’importanza di una manifestazione, solitamente gli atleti in gara sono in numero
elevato: si definiscono allora i concentramenti giornalieri, cioè parti in cui la
manifestazione viene scomposta, caratterizzati da un numero di programma univoco, dalla
data in cui si svolgono e dagli impianti che occupano: per evitare spostamenti, si richiede
che questi ultimi siano nella stessa località, e si richiede la presenza di almeno 4 categorie e
5 discipline.
In ogni concentramento ci possono essere al massimo 20 gare, ognuna delle quali vedrà
protagonisti atleti di una ceta categoria in una determinata disciplina.
Allenatori – Atleti – Società
I protagonisti di tutto questo sono naturalmente gli atleti: sicuramente è necessario
conoscere i loro principali dati personali, come il codice fiscale, il nominativo, l’indirizzo e
la data di nascita; in più, degli allenatori è utile avere la data di inizio insegnamento,
mentre per gli atleti quella di inizio attività.
Sia allenatori che atleti possono o meno essere tesserati, nell’anno in corso, presso una
società, individuata univocamente attraverso un codice e descritta con dati come l’indirizzo,
la data di fondazione, il telefono e il numero di atleti ed allenatori iscritti.
Sebbene da questa descrizione possa sembrare che atleti, allenatori e società, che
costituiscono il cuore dell’organizzazione, siano stati descritti in modo sommario, ciò si
deve al fatto che si è reputato più interessante chiarire le relazioni tra le parti in causa
piuttosto che scendere nel dettaglio in argomenti peraltro già noti.
Cartellini – Punteggi – Trofei
La prestazione di un determinato atleta in una specifica gara è registrata materialmente in un
documento cartaceo che viene definito cartellino: in esso si annotano la gara, la data, con
quale punteggio l’atleta si era presentato alla gara appena svolta ed il punteggio
effettiamente ottenuto, annotando se vi è stata squalifica oppure ritiro. A questo punto si
deve specificare che i cartellini sono la tangibile registrazione delle prove sostenute dagli
atleti durante l’anno agonistico in corso: un discorso diverso va fatto per quanto riguarda le
necessarie funzionalità di archivio, che tra l’altro devono necessariamente tenere conto del
fatto che un atleta potrebbe essre stato tesserato in diverse società durante gli anni.
Si è precedentemente accennato al fatto che tra tutte le manifestazioni un posto particolare
lo occupano i trofei, e questo in quanto a livello nazionale sono tipi di gara molto diffusi.
INGEGNERIA DEL SOFTWARE
5
CAPITOLO 1 – SPECIFICHE DI PROGETTO
La descrizione di un trofeo ricalca quella della manifestazione, ma in più è possibile
specificare anche la cadenza temporale di questo evento; sempre per quest’ultimo, è
possibile che gli organizzatori vogliano conferire ad esso un carattere più tipico.
Quest’ultima osservazione ricorda che può essere utile definire schemi di punteggi, cioè
sequenze, identificate univocamente da un codice, che contengano la lista dei punti che in
un trofeo di quel tipo si reputa giusto assegnare ai vari atleti classificati.
1.2 Funzionalità richieste
Funzionalità di visualizzazione
•
Visualizzazione di tutte le gare a cui ha partecipato un atleta nell’anno agonistico.
•
Visualizzazione di tutte le manifestazioni patrocinate da una data federazione.
•
Visualizzazione di tutte le gare che si sono svolte in una certa data.
•
Visualizzazione di tutti gli atleti attualmente tesserati presso una data società.
•
Visualizzazione di tutti gli allenatori attualmente tesserati presso una data società.
•
Visualizzazione di tutte le manifestazioni che si svolgono in data odierna.
•
Visualizzazione del numero di manifestazioni di tipo ufficiale a cui ha partecipato nei
precedenti anni agonistici un dato atleta.
Funzionalità di inserimento e modifica
6
•
Inserimento di un nuovo atleta in una società già esistente.
•
Inserimento di una nuova gara in un concentramento già esistente.
•
Aggiornamento percentuale dello stipendio di un atleta in una certa società.
•
Aggiornamento del numero di corsie e della lunghezza massima di un impianto.
•
Eliminazione di un atleta e delle sue prestazioni nell’anno agonistico corrente.
•
Eliminazione di uno schema di punteggi.
INGEGNERIA DEL SOFTWARE
2
Modello Statico
2.1 Discipline - Impianti - Categorie
Value Distanza
Lungh: integer mandatory
laws
L1: (Lungh gt 0) and (Lungh le 1000)
L2: Lungh mod 25 eq 0
Commento: L1 controlla che la distanza sia tra la minima e la massima consentite; L2 forza la
distanza presente ad essere un multiplo di 25, come da prassi nella disciplina.
****
Value Anno
Valore: 1900…2100 mandatory
Bisest: boolean mandatory
laws
L1: Bisest ⇔ ((Valore mod 4 eq 0) and (Valore mod 100 ne 0)) or (Valore mod 400 eq 0)
Commento: si tiene conto, per validare la presenza di un anno, delle scadenze bisestili.
****
Virtual Dist&Dist (d1, d2: Distanza)
Seconda-maggiore: boolean
Uguali: boolean
INGEGNERIA DEL SOFTWARE
Gestione gare di tiro con l’arco
CAPITOLO 2 – MODELLO STATICO
laws
L1: Seconda-maggiore ⇔ d1.Lungh lt d2.Lungh
L2: Uguali ⇔ d1.Lungh eq d2.Lungh
Commento: questo virtual permette il confronto tra due distanze sia a livello di uguaglianza che
di disuguaglianza.
****
Value Data
Giorno: 1…31 mandatory
Mese: 1…12 mandatory
An: Anno mandatory
laws
L1: Mese in (4,6,9,11) ⇒ Giorno le 30
L2: An.Bisest and (Mese eq 2) ⇒ Giorno le 29
L3: not (An.Bisest) and (Mese eq 2) ⇒ Giorno le 28
Commento: la definizione di data è banale; merita comunque attenzione il mese di Febbraio, per
il quale va controllato il fatto che l’anno sia bisestile oppure no.
****
Virtual Data&Data (d1, d2: Data)
Seconda-maggiore: boolean
Uguali: boolean
laws
L1: Seconda-maggiore ⇔ (d1.An lt d2.An) or ((d1.An eq d2.An) and (d1.Mese lt d2.Mese))
or ((d1.An eq d2.An) and (d1.Mese eq d2.Mese) and (d1.Giorno lt d2.Giorno))
L2: Uguali ⇔ (d1.An eq d2.An) and (d1.Mese eq d2.Mese) and (d1.Giorno eq d2.Giorno)
Commento: questo virtual consente di compiere il confronto fra due date; è del tutto analogo al
precedente virtual per il confronto di due distanze.
****
Value Intervallo-data
data1: Data mandatory
data2: Data mandatory
laws
L1: Data&Data(d1=data1, d2=data2).Seconda-maggiore or Data&Data(d1=data1,
d2=data2).Uguali
Commento: è parso conveniente rappresentare il concetto di intervallo in un value piuttosto che
trattare singolarmente due date: è allora necessario controllare che la data di fine sia successiva
o al limite coincidente con la data di inizio.
8
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
Virtual Data&Intervallo (d:Data, i: Intervallo-data)
Appartiene: boolean
laws
L1: Appartiene ⇔ ((Data&Data(d1=i.data1, d2=d).Seconda-maggiore) or
(Data&Data(d1=i.data1, d2=d).Uguali)) and ((Data&Data(d1=d, d2=i.data2).Secondamaggiore) or (Data&Data(d1=d, d2= i.data2).Uguali))
Commento: questo virtual permette di confrontare un intervallo temporale con una data, e
consente di stabilire l’appartenenza della data allo stesso (la data in questione può coincidere
anche con l’inizio o con la fine dell’intervallo).
****
Value Indirizzo
Genere: (piazza, via, viale) mandatory
Nome: string mandatory
Numero: string
Cap: listof 0…9 mandatory
Localitá: string mandatory
Provincia: listof A…Z
laws
L1: card (Cap) eq 5
L2: Numero gt 0
L3: card (Provincia) eq 2
Commento: l’indirizzo viene qui riassunto nelle sue caratteristiche salienti; in particolare si è
posta attenzione alle codifiche del Codice di Avviamento Postale (L1) e della Provincia (L3).
****
Object Disciplina
Lunghezza: Distanza mandatory
Modalitá: (apunti, torneo, girone) mandatory
Descrizione: string
class attributes
MaxDistAttuale: integer
laws
L1: let maxlung = max (~GET_STRING_LENGTH (d.Descrizione) for d in Instances)
L2: maxlung le 255
L3: forall d1, d2 in Instances itis (ident (d1) eq ident (d2) ⇔ (d1.Lunghezza eq
d2.lunghezza) and (d1.Modalitá eq d2.Modalitá))
L4: MaxDistAttuale eq max (d.Lunghezza for d in Instances)
Commento: la disciplina è caratterizzata da una lunghezza di tiro e da una modalitá; L1 ed L2
controllano che il campo che descrive la discplina in questione sia sufficientemente piccolo
INGEGNERIA DEL SOFTWARE
9
CAPITOLO 2 – MODELLO STATICO
attraverso l’invocazione di una funzione esterna che calcola la lunghezza di una stringa. L3 si
occupa di controllare l’identitá di un oggetto disciplina mentre L4 descrive la massima distanza
utilizzata correntemente dall’insieme delle discipline.
****
Object Impianto
Nome: string mandatory
LunghMax: Distanza mandatory
Ncorsie: integer mandatory
Luogo: Indirizzo mandatory
laws
L1: forall i1, i2 in Instances itis (ident (i1) eq ident (i2) ⇔ (i1.Nome eq i2.Nome) and
(i1.Luogo eq i2.Luogo))
L2: (Ncorsie ge 4) and (Ncorsie le 50)
Commento: un impianto è identificato univocamente dal nome e dal luogo in cui sorge (si pensi
ad esso come ad un campo di tiro con l’arco o a piú campi adiacenti); l’unico vincolo che si
pone è la definizione di un range di “corsie” accettabile per tutte le strutture in attivitá (legge
L2).
****
Object Categoria
Nome: string mandatory
Sesso: (M, F) mandatory
EtaInizio: integer mandatory
EtaFine: integer mandatory
class attributes
NumCateg: integer
laws
L1: forall c1, c2 in Instances itis (ident (c1) eq ident (c2) ⇔ (c1.Nome eq c2.Nome) and
(c1.Sesso eq c2.Sesso))
L2: NumCateg eq card (c in Instances)
L3: (EtaInizio gt 6) and (EtaFine lt 80)
L4: EtaInizio le EtaFine
Commento: come espresso da L1, una categoria viene individuata univocamente dalla coppia
<nome-sesso>; L3 ed L4 si occupano invece di controllare i limiti di etá minimi e massimi
(EtaInizio ed EtaFine) previsti dalla categoria in questione.
****
10
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
Giorno
Distanza
Lungh
Mese
integer
Data
data2
An
data1
Intervallo-data
1900...2100
Seconda-maggiore
Uguali
Data&Data
Appart
ie
st
se
i
B
ne
e
Valor
boolean
Anno
Seconda-maggiore
Uguali
Data&Intervallo
Dist&Dist
piazza
via
viale
Genere
Nome
string
Numero
Indirizzo
Cap listof
0...9
Localitá
Provincia listof
A...Z
Vers
dimostrativ
Figura 1: Virtual e Value iniziali
INGEGNERIA DEL SOFTWARE
11
CAPITOLO 2 – MODELLO STATICO
apunti
torneo
girone
Mo
dal
M
le
tua
tAt
s
i
axD
integer
itá
Disciplina
De
scr
izio
ne
Lunghezza
Distanza
string
Lu
ng
hM
e
Nom
ax
Impianto
Lu
o
og
rs
Nco
ie
Indirizzo
integer
EtaInizio
Eta
Fin
e
NumCateg
Categoria
Nom
e
Sesso
string
M
F
Vers
dimostrativ
Figura 2: Discipline – Impianti - Categorie
12
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
2.2 Federazioni – Manifestazioni – Concentramenti – Gare
Object Manifestazione
Codman: integer mandatory unique
Tipo: (normale, trofeo)
Intervallo: Intervallo-data mandatory
Denominazione: (ufficiale, nonufficiale) mandatory
Descrizione: string
laws
L1: let maxlung = max (~GET_STRING_LENGTH (m.Descrizione) for m in Instances)
L2: maxlung le 255
L3: Codman gt 0
Commento: si pensi ad una manifestazione come, ad esempio, ad un campionato nazionale
oppure ad una grande rassegna; ad essa corrisponderanno vari concentramenti.
Codman è il numero che identifica univocamente l’oggetto; quest’ultimo puó essere un trofeo
(come vedremo in seguito). Intervallo descrive la durata temporale della manifestazione, mentre
il valore dell’attributo Denominazione dipende dal fatto che la manifestazione sia organizzata o
meno da una federazione.
Come giá visto in precedenza, L1 ed L2 utilizzano una funzione esterna che si assume essere
presente nel sistema, permettendoci cosí di controllare la lunghezza dei campi di descrizione. L3
impone semplicemente la positivitá del codice univoco di identificazione della manifestazione.
****
Object Federazione
Sigla: string mandatory unique
Nome: string mandatory
laws
L1: forall f1, f2 in Instances itis (ident (f1) eq ident (f2) ⇔ f1.Nome eq f2.Nome)
Commento: sebbene una federazione sia identificata esplicitamente da una sigla, è parso corretto
imporre anche il vincolo sull’unicitá del nome: è estremamente improbabile infatti che esistano
due fedrazioni con lo stesso nome nell’ambito dello stesso sport (Nome diventa quindi una
“chiave alternativa”).
****
Context FedOrgMan
Man: Manifestazione mandatory
Fed: Federazione mandatory
laws
L1: forall m in Manifestazione.Instances suchthat (m.Denominazione eq ufficiale) itis (exists
fom in Instances suchthat (ident (m) eq ident (fom.Man)))
INGEGNERIA DEL SOFTWARE
13
CAPITOLO 2 – MODELLO STATICO
L2: forall fom1, fom2 in Instances suchthat (ident (fom1) ne ident (fom2)) itis (ident
(fom1.Man) ne ident (fom2.Man))
L3: forall fom in Instances itis (exists m in Manifestazione.Instances suchthat (ident
(fom.Man) eq ident (m)))
L4: forall fom in Instances itis (exists f in Federazione.Instances suchthat (ident (fom.Fed) eq
ident (f)))
Commento: questo context crea un legame tra le manifestazioni e le federazioni che le
organizzano.
L1 controlla che in corrispondenza ad ogni manifestazione classificata come ufficiale esista in
effetti una federazione che l’ha organizzata; che quest’ultima sia anche unica è un controllo
svolto da L2. L3 ed L4 sono vincoli di integritá referenziale: ogni elemento in questo context
deve fare riferimento rispettivamente ad una manifestazione ed a una federazione giá esistenti
nei rispettivi object.
La natura stessa del context ci garantisce che due determinate istanze degli object
Manifestazione e Federazione son presenti al massimo in un’unica istanza di FedOrgMan.
****
Object Concentramento
Man: Manifestazione mandatory
Nprog: integer mandatory
Dataevento: Data mandatory
Impianti: setof Impianto mandatory
DistMax: Distanza
laws
L1:DistMax eq max (i.LunghMax for i in Impianti)
L2: forall c in Instances itis (forall i1, i2 in Impianti suchthat (ident (c.i1) ne ident (c.i2)) itis
(c.i1.Luogo.Localitá eq c.i2.Luogo.Localitá))
L3: forall c1, c2 in Instances itis (ident (c1) eq ident (c2) ⇔ (c1.Nprog eq c2.Nprog) and
(ident (c1.Man) eq ident (c2.Man)))
L4: Nprog gt 0
L5: forall c in Instances itis (Data&Intervallo (d=c.Dataevento,
i=c.Man.Intervallo).Appartiene)
L6: forall c in Instances itis (exists unique m in Manifestazione.Instances suchthat
(c.Man.Codman eq m.Codman))
L7: forall c in Instances itis ((card (i in c.Impianti) ge 1) and (card (i in c.Impianti) le 10))
L8: forall m in Manifestazione.Instances itis ((card (c in Instances where (ident (c.Man) eq
ident (m))) gt 0) and (card (c in Instances where (ident (c.Man) eq ident (m))) le 10))
Commento: L2 ci dice come in un concentramento, oggetto che fa parte di una manifestazione,
i diversi impianti debbano risiedere nella stessa localitá; inoltre questi ultimi devono essere al
massimo 10 (L7). L3 identifica univocamente un oggetto di questo tipo con la manifestazione
entro cui si svolge e il numero di programma che gli è stato assegnato, mentre L6 controlla che
ogni concentramento sia assegnato ad un’unica manifestazione. Sempre a causa di questa
relazione di inclusione, è necessario che il giorno in cui si svolge un concentramento sia
nell’intervallo temporale che caratterizza la manifestazione associata (L5); quest’ultima puó poi
essere articolata al massimo in 10 concentramenti, come si puó notare da L8.
14
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
Context Gara
Disc: Disciplina mandatory
Conc: Concentramento mandatory
Cat: Categoria mandatory
NumGare: integer mandatory
laws
L1: forall c in Concentramento.Instances itis (exists g in Instances suchthat (ident (c) eq
ident (g.Conc)))
L2: forall c in Concentramento.Instances itis (card (g in Instances where (ident (g.Conc) eq
ident (c))) le 20)
L3: forall g in Instances itis (exists c in Concentramento.Instances suchthat (ident (g.Conc)
eq ident (c)))
L4: forall g in Instances itis (exists d in Disciplina.Instances suchthat (ident (g.Disc) eq ident
(d)))
L5: forall g in Instances itis (exists c in Categoria.Instances suchthat (ident (g.Cat) eq ident
(c)))
L6: forall g in Instances itis (Dist&Dist (d1=g.Disc.Lunghezza,
d2=g.Conc.DistMax).Seconda-maggiore or Dist&Dist (d1=g.Disc.Lunghezza,
d2=g.Conc.DistMax).Uguali)
L7: forall c in Concentramento.Instances itis (card (g.Disc for g in Instances where (ident (c)
eq ident (g.Conc))) ge 5)
L8: forall c in Concentramento.Instances itis (card (g.Cat for g in Instances where (ident (c)
eq ident (g.Conc))) ge 4)
L9: forall g in Instances itis (g.NumGare eq card (f in Instances where (ident (g.Conc) eq
ident (f.Conc))))
Commento: ricordiamo prima di tutto che la natura del context ci garantisce il fatto che la
singola tripla di istanze < disciplina – concentramento – gara > si possa presentare una sola
volta in tutte le istanze di Gara.
In ogni concentramento non solo è presente almeno una gara (legge L1) ma si richiede inoltre
che ce ne siano al massimo 20 (legge L2). E’ inoltre necessario assicurarsi che la presenza di
concentramenti, discipline e categorie in questo context implichi la presenza delle stesse nei
rispettivi object: queste relazioni di integritá referenziale sono espresse rispettivamente dalle
laws L3, L4 ed L5.
La legge L6 invece controlla che per ogni disciplina (caratterizzata anche dalla distanza di tiro)
che è presente nella manifestazione, esista almeno un concentramento che contiene un impianto
capace di ospitare gare su quella distanza. Viene inoltre fissato il numero minimo di discipline
(5) e di categorie (4) che possono partecipare ad una gara in ogni concentramento, grazie alle
leggi L7 ed L8. In ultimo, L9 permette di verificare il numero di gare presenti in ogni
concentramento.
****
INGEGNERIA DEL SOFTWARE
15
CAPITOLO 2 – MODELLO STATICO
Federazione
Fed
Nome
la
Sig
FedOrgMan
Den
om
inaz
izi
on
ione
Intervallo
Intervallo-data
Tipo
M
Cod
normale
trofeo
e
M
De
scr
ufficiale
nonufficiale
an
string
Manifestazione
an
n
Ma
integer
Np
Impianto
rog
Impianti setof
Dataevento
Data
Concentramento
ax
Conc
tM
Dis
Distanza
Disciplina
Disc
Categoria
Cat
Gara
N
integer
G
um
e
ar
Vers
dimostrativ
Figura 3: Federazioni – Manifestazioni – Concentramenti – Gare
16
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
2.3 Allenatori – Atleti – Società
Value Punteggio
Numero: integer mandatory
laws
L1: Numero ge 0
Commento: è opportuno creare questo value per incapsulare il numero assieme alla sua legge,
che altrimenti dovrebbe essere ripetuta ogni volta.
****
Value Telefono
Prefisso: listof 0…9 mandatory
Numero: listof 0…9 mandatory
Tipo: (domestico, cellulare, affari) mandatory
laws
L1: card (Prefisso) ge 2
L2: card (Prefisso) le 4
L3: first (Prefisso) eq 0
L4: card (Prefisso) ge 5
Commento: la descrizione di un numero di telefono è abbastanza semplice; tuttavia è necessario
evidenziare come sia necessario implementare il Prefisso ed il Numero come liste e non come
interi, in quanto sono significativi in questo caso anche gli zeri iniziali.
****
Object Persona
CodFisc: string mandatory unique
Nome: string mandatory
Cognome: string mandatory
Sesso: (M, F) mandatory
Ind: Indirizzo mandatory
TelCasa: Telefono
TelUfficio: Telefono
TelCell: Telefono
DataNascita: Data mandatory
LuogoNascita: string mandatory
Ruolo: string mandatory
laws
L1: (TelCasa ne null) or (TelUfficio ne null) or (TelCell ne null)
L2: TelCasa ne null ⇒ TelCasa.Tipo eq domestico
L3: TelUfficio ne null ⇒ TelUfficio.Tipo eq affari
INGEGNERIA DEL SOFTWARE
17
CAPITOLO 2 – MODELLO STATICO
L4: TelCell ne null ⇒ TelCell.Tipo eq cellulare
Commento: si è tentato di dare qui una descrizione abbastanza completa (ai fini di questo
lavoro) della generica persona, identificata univocamente dal suo codice fiscale; tutto questo
sará utile per definire specializzazioni pertinenti alle societá sportive.
****
Object Allenatore isa Persona
Descrizione: string
InizioInsegn: Data mandatory
Tesserato: boolean mandatory
class attributes
NumTotAll: integer
laws
L1: Ruolo eq allenatore
L2: ~GET_STRING_LENGTH (Descrizione) le 255
L3: NumTotAll eq card (a in Instances where (a.Tesserato))
Commento: questa specializzazione è caratterizzata dall’aggiunta della data di inizio
insegnamento ma soprattutto dal flag Tesserato, che discrimina un allenatore attualmente in
attivitá presso una societá da uno temporaneamente inattivo.
****
Object Atleta isa Persona
Curriculum: string
InizioAttivitá: Data mandatory
Tesserato: boolean mandatory
PuntMax: Punteggio
class attributes
NumTotAtl: integer
laws
L1: Ruolo eq atleta
L2: ~GET_STRING_LENGTH (Curriculum) le 255
L3: NumTotAtl eq card (a in Instances where (a.Tesserato))
Commento: le leggi per la descrizione di un atleta sono analoghe a quelle giá viste per
l’allenatore; anche qui è importante il flag Tesserato che discrimina tra atleti in attivitá oppure
no.
****
Object Societá
CodSoc: integer mandatory unique
NomeSoc: string mandatory
Ind: Indirizzo mandatory
18
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
NumAtleti: integer
NumAllen: integer
PuntMax: Punteggio
DataFond: Data
TelUfficio: Telefono
Descrizione: string
class attributes
NumMedAtl: integer
NumMedAll: integer
laws
L1: CodSoc gt 0
L2: TelUfficio.Tipo eq affari
L3: ~GET_STRING_LENGTH (Descrizione) le 255
L4: NumMedAtl eq avg (s.NumAtleti for s in Instances)
L5: NumMedAll eq avg (s.NumAllen for s in Instances)
L6: (NumAtleti ge 5) and (NumAllen ge 1)
Commento: una societá è caratterizzata univocamente dal codice societario che le viene
attribuito, che deve essere un intero positivo (legge L1). Si è scelto di porre un limite per il
numero di atleti ed allenatori minimo (L6), sebbene non sia troppo vincolante. E’ possibile
verificare inoltre il numero medio di atleti e allenatori nelle societá grazie ai due attributi di
classe NumMedAll e NumMedAtl che si basano sugli attributi NumAtleti e NumAllen (leggi
L4 e L5).
****
Context AllinSoc
All: Allenatore mandatory
Soc: Società mandatory
Stipendio: integer
laws
L1: forall a in Allenatore.Instances suchthat (a.Tesserato) itis (exists unique as in Instances
suchthat (ident (as.All) eq ident (a)))
L2: forall a in Allenatore.Instances suchthat (not a.Tesserato) itis (not exists as in Instances
suchthat (ident (as.All) eq ident (a)))
L3: forall as in Instances itis (exists a in Allenatore.Instances suchthat (ident (as.All) eq ident
(a)))
L4: forall as in Instances itis (exists s in Società.Instances suchthat (ident (as.Soc) eq ident
(s)))
L5: forall s in Società.Instances itis (exists as in Instances suchthat (ident (s) eq ident
(as.Soc)))
L6: forall s in Società.Instances itis (s.NumAllen eq card (as in Instances where (ident (s) eq
ident (as.Soc))))
Commento: questo context lega l’oggetto allenatore con l’oggetto società; prima di tutto si deve
controllare che ogni allenatore che figura come tesserato sia effettivamente presente in una sola
società, e che uno non tesserato non sia presente in nessuna: questo viene espresso dalle leggi
INGEGNERIA DEL SOFTWARE
19
CAPITOLO 2 – MODELLO STATICO
L1 ed L2. Inoltre anche qui vengono esplicitati i vincoli di integrità referenziale, che richiedono
la presenza effettiva, nei rispettivi object, delle società e degli allenatori presenti in questo
context (leggi L4 ed L3). L5 controlla che almeno uno di questi ultimi sia presente in ogni
società, cioè che ogni istanza di questa sia presente in almeno un’istanza del context; il numero
di partecipazioni deve coincidere con l’attributo (dell’oggetto società) NumAllen, e questo
viene verificato da L6.
Si ricorda inoltre che la natura del context fa in modo che una determinata coppia di istanze
<allenatore – società> sia presente una sola volta nelle istanze di AllinSoc.
****
Context AtlinSoc
Atl: Atleta mandatory
Soc: Società mandatory
Stipendio: integer
laws
L1: forall a in Atleta.Instances suchthat (a.Tesserato) itis (exists unique as in Instances
suchthat (ident (as.Atl) eq ident (a)))
L2: forall a in Atleta.Instances suchthat (not a.Tesserato) itis (not exists as in Instances
suchthat (ident (as.Atl) eq ident (a)))
L3: forall as in Instances itis (exists a in Atleta.Instances suchthat (ident (as.Atl) eq ident
(a)))
L4: forall as in Instances itis (exists s in Società.Instances suchthat (ident (as.Soc) eq ident
(s)))
L5: forall s in Società.Instances itis (card (as in Instances where (ident (s) eq ident (as.Soc)))
ge 5)
L6: forall s in Società.Instances itis (s.PuntMax eq max (a.PuntMax for a in Atleta.Instances
where (exists as in Instances suchthat ((ident (s) eq ident (as.Soc)) and (ident (a) eq ident
(as.Atl))))))
L7: forall s in Società.Instances itis (s.NumAtleti eq card (as in Instances where (ident (s) eq
ident (as.Soc))))
Commento: le leggi elencate qui sopra sono del tutto analoghe a quelle già viste nel context
precedente; anche qui vengono controllate rispettivamente: il fatto che un atleta tesserato sia
attivo presso una sola società (L1) e che un atleta dichiarato inattivo non sia presente in nessuna
istanza di questo context (L2); anche qui vengono ripresi i vincoli di integrità referenziale
attraverso le leggi L3 ed L4. L5 esprime il vincolo, peraltro esplicitato anche nell’object
Società, che a quest’ultima siano iscritti almeno cinque atleti; il loro numero preciso, contenuto
nell’attributo NumAtleti, viene validato con la legge L7. Rispetto al precedente context viene
aggiunta L6, che permette di controllare il punteggio massimo “raggiunto” da ogni società, cioè
il massimo dei punteggi conseguiti tra tutti gli atleti iscritti a quest’ultima.
****
Context AllconAtl by AllinSoc, AtlinSoc
All: Allenatore
Atleti: setof Atleta
Numero: integer
20
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
laws
L1: forall atl in Atleti itis (exists ats in AtlinSoc.Instances, als in AllinSoc.Instances suchthat
((ident (atl) eq ident (ats.Atl)) and (ident (ats.Soc) eq ident (als.Soc)) and (ident (als.All) eq
ident (All))))
L2: forall als in AllinSoc.Instances suchthat (ident (als.All) eq ident (All)) itis (forall ats in
AtlinSoc.Instances suchthat ( ident (ats.Soc) eq ident (als.Soc)) itis (exists atl in Atleti
suchthat (ident (ats.Atl) eq ident (atl))))
L3: Numero eq card (Atleti)
Commento: dato che i due context utilizzati interessano un object comune (la societá) e si
vogliono mettere in relazione gli altri due concetti (gli allenatori e gli atleti), si è scelto di
utilizzare la primitiva context by. Preso un allenatore, tesserato presso una certa societá, si
ottiene la lista di tutti gli atleti iscritti alla stessa societá dell’allenatore e la validitá della lista
viene controllata da due leggi: L1 esprime il vincolo che per ogni istanza di atleta presente in
Atleti devono esistere due istanze nei context AtlinSoc e AllinSoc che contengono
rispettivamente questo atleta e l’allenatore considerato, e che hanno la stessa istanza
dell’oggetto Societá. L2 invece considera il passaggio logico “inverso”: per ogni istanza di
AllinSoc in cui l’object Allenatore ha l’identitá considerata, si controlla che, in ogni istanza di
AtlinSoc che ha la stessa societá, ci sia un’istanza di Atleta presente anche in Atleti.
****
Context SocOrgMan
Soc: Societá mandatory
Man: Manifestazione mandatory
Budget: integer
laws
L1: forall m in Manifestazione.Instances itis (exists unique som in Instances suchthat (ident
(m) eq ident (som.Man)))
L2: forall s in Societá.Instances itis (card (som in Instances where (ident (s) eq ident
(som.Soc))) le 10)
L3: forall som in Instances itis (exists s in Societá.Instances suchthat (ident (som.Soc) eq
ident (s)))
L4: forall som in Instances itis (exists m in Manifestazione.Instances suchthat (ident
(som.Man) eq ident (m)))
Commento: qui si mettono in relazione gli eventi di tipo manifestazione con le societá che li
organizzano: in particolare, una manifestazione deve essere organizzata da una sola societá
(legge L1), mentre quest’ultima (per evitare “monopoli” a livello sportivo) puó organizzare al
massimo dieci manifestazioni (legge L2). Inoltre viene tenuto conto anche dei vincoli di
integritá referenziale, controllando che ad ogni istanza di Manifestazione e di Societá presente
in SocOrgMan corrisponda in effetti un’istanza nei rispettivi oggetti.
Infine, anche qui la natura del context ci garantisce che ogni determinata coppia di istanze
<societá – manifestazione> sia presente una sola volta nell’insieme delle istanze di SocOrgMan.
****
INGEGNERIA DEL SOFTWARE
21
CAPITOLO 2 – MODELLO STATICO
Context PartecAtl
Atl: Atleta mandatory
Soc: Societá mandatory
Man: Manifestazione mandatory
laws
L1: forall pa1, pa2 in Instances itis (ident (pa1) eq ident (pa2) ⇔ (ident (pa1.Atl) eq ident
(pa2.Atl)) and (ident (pa1.Man) eq ident (pa2.Man)))
L2: forall pa in Instances itis (exists a in Atleta.Instances suchthat (ident (pa.Atl) eq ident
(a)))
L3: forall pa in Instances itis (exists s in Societá.Instances suchthat (ident (pa.Soc) eq ident
(s)))
L4: forall pa in Instances itis (exists m in Manifestazione.Instances suchthat (ident (pa.Man)
eq ident (m)))
L5: forall pa in Instances itis (Data&Data (d1=pa.Soc.DataFond,
d2=pa.Man.Intervallo.data1).Seconda-maggiore or Data&Data (d1=pa.Soc.DataFond,
d2=pa.Man.Intervallo.data1).Uguali)
L6: forall pa in Instances itis (Data&Data (d1=pa.Atl.InizioAttivitá,
d2=pa.Man.Intervallo.data1).Seconda-maggiore or Data&Data (d1= pa.Atl.InizioAttivitá,
d2=pa.Man.Intervallo.data1).Uguali)
Commento: a differenza dei precedenti concetti, questo context si occupa dei dati “storici”:
mentre infatti prima ci si preoccupava di esplicitare le leggi che verificano la validitá dei dati
per la stagione agonistica in corso, qui ci sono le regole che validano i dati inseriti nelle gare
precedenti, anche nei passati anni agonistici. La natura del context ci dice che una tripla <atleta
– societá – manifestazione> si puó presentare una sola volta tra le istanze del context PartecAtl;
questo peró in questo caso non basta, poiché se da un lato è possibile che un atleta abbia militato
in piú societá, dall’altro è necessario che una coppia <atleta – manifestazione> si presenti una
sola volta. In sostanza la partecipazione dell’atleta ad una manifestazione deve avvenire sotto i
colori di un’unica societá, e per questo è presente la legge L1. I vincoli di integritá referenziale
vengono considerati attraverso L2, L3 ed L4, che garantiscono che le entitá di Atleta, Societá e
Manifestazione presenti in questo context lo siano anche nei rispettivi object. L5 ed L6
controllano che le date di inizio attivitá (per ogni atleta) e di fondazione (per ogni societá) siano
anteriori alla data che segna l’inizio della manifestazione.
****
22
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
M
F
Data
Indirizzo
ta
ci
as
Ses
so
aN
at
D
Nome
0...9
d
In
Numero listof
Cognome
TelCasa
CodFisc
string
Prefisso listof
TelUfficio
Persona
LuogoNascita
Telefono
TelCell
Ruolo
Tipo
domestico
cellulare
affari
Curriculum
Data
Iniz
ioA
ttiv
it
Nu
mT
otA
Punteggio
ax
Atleta
InizioInsegn
Allenatore
De
scr
izi
tl
ntM
Pu
á
Tesserato
Tesserato
Data
on
e
NumTotAll
string
Numero
boolean
integer
integer
Vers
dimostrativ
Figura 4: Allenatori - Atleti
INGEGNERIA DEL SOFTWARE
23
CAPITOLO 2 – MODELLO STATICO
integer
CodSoc
NumMedAll
NumAllen
Data
Dat
aF
NumAtleti
ffic
lU
Te
ond
PuntMax
Punteggio
NumMedAtl
Telefono
io
Societá
Ind
Des
NomeSoc
criz
io
ne
string
Indirizzo
Soc
Soc
Allenatore
Atleta
All
Atl
AllinSoc
AtlinSoc
All
Atleti setof
by
by
AllconAtl
Vers
dimostrativ
Sticazzi
Figura 5: Società
24
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
2.4 Cartellini – Punteggi - Trofei
Context Cartellino
Atl: Atleta mandatory
Gar: Gara mandatory
Dat: Data mandatory
PuntIscr: Punteggio mandatory
PuntGara: Punteggio
Segnalazioni: (ritirato, squalificato)
laws
L1: forall c in Instances itis (exists a in Atleta.Instances suchthat (ident (c.Atl) eq ident (a)))
L2: forall c in Instances itis (exists g in Gara.Instances suchthat (ident (c.Gar) eq ident (g)))
L3: forall g in Gara.Instances itis (card (c.Atl in Instances where (ident (g) eq ident (c.Gar)))
ge 2)
L4: forall g in Gara.Instances itis (card (c.Atl in Instances where (ident (g) eq ident (c.Gar)))
le 50)
L5: forall c in Instances itis (Data&Data(d1=c.Dat, d2=c.Gar.Conc.Dataevento).Uguali)
L6: PuntGara ne null ⇒ Segnalazioni eq null
L7: Segnalazioni ne null ⇒ PuntGara eq null
L8: (PuntGara ne null) or (Segnalazioni ne null)
L9: forall c in Instances itis (Data&Data (d1=c.Atl.InizioAttivitá,
d2=c.Gar.Conc.Dataevento).Seconda-maggiore or Data&Data (d1=c.Atl.InizioAttivitá,
d2=c.Gar.Conc.Dataevento).Uguali)
L10: forall a in Atleta.Instances itis (a.PuntMax eq max (c.PuntGara for c in Instances where
(ident (a) eq ident (c.Atl))))
Commento: un cartellino identifica univocamente la partecipazione di un atleta ad una gara
dell’anno agonistico in corso. E’ quindi necessario controllare che gli atleti e le gare contenute
nelle istanze di questo context siano effettivamente presenti nei rispettivi object: questi vincoli
di integritá referenziale vengono descritti dalle leggi L1 ed L2. Il numero di atleti che possono
partecipare alla singola gara è stabilito tra 2 e 50: il rispetto di questa regola è verificato dalle
leggi L3 ed L4. Inoltre puó essere opportuno controllare che la data propria del concentramento
(e quindi anche della gara) coincida con la data sul cartellino che documenta la presenza
dell’atleta alla gara in questione (L5). La prestazione di un atleta in una gara puó dare luogo o
ad un certo punteggio oppure ad un’annotazione che conferma una situazione particolare: la
presenza di un valore in PuntGara e Segnalazioni è quindi mutuamente esclusiva, e questo è
controllato dalle leggi L6,L7 ed L8. L9 si fa carico di verificare che la data che segna l’inizio
dell’attivitá di ogni atleta sia precedente (o al massimo coincidente) rispetto alla data presente
sul cartellino; L10 controlla infine che l’attributo PuntMax dell’oggetto Atleta sia in effetti il
massimo punteggio conseguito dall’atleta in questione in tutte le gare da esso disputate.
Anche qui la natura del context garantisce che una determinata coppia di istanze <atleta - gara>
si presenti una sola volta in tutte le istanze di Cartellino.
****
INGEGNERIA DEL SOFTWARE
25
CAPITOLO 2 – MODELLO STATICO
Object Trofeo isa Manifestazione
Periodicitá: (annuale, biennale, triennale, quadriennale)
NumSch: integer
laws
L1: Tipo eq trofeo
L2: NumSch ge 1
Commento: questo object è una specializzazione dell’oggetto Manifestazione; in particolare un
trofeo solitamente ha una propria periodicitá e adotta uno o piú schemi di punteggio (vedi
sotto).
****
Object SchemaPunteggi
CodSchema: integer mandatory unique
ListPunt: listof Punteggio mandatory
Osservazioni: string
NumPunt: integer mandatory
NumTr: integer
laws
L1: CodSchema gt 0
L2: NumPunt ge 3
L3: card (ListPunt) eq NumPunt
L4: ~GET_STRING_LENGTH (Osservazioni) le 255
L5: NumTr ge 1
Commento: uno schema di punteggi è identificato univocamente da un codice che gli viene
attribuito; è costituito da una lista ordinata di punteggi e in particolare sono presenti due
attributi: NumPunt descrive quanti atleti avranno un punteggio maggiore di zero, cioè qual’è la
cardinalitá della lista ListPunt; NumTr è il numero di trofei che utilizzano quel determinato
schema di punteggio. Anche qui è presente la funzione “esterna” GET_STRING_LENGTH
(string), che restituisce la lunghezza della lista passata.
****
Context PuntinTr
Tr: Trofeo mandatory
SchPunt: SchemaPunteggi mandatory
laws
L1: forall t in Trofeo.Instances itis (exists pt in Instances suchthat (ident (t) eq ident (pt.Tr)))
L2: forall s in SchemaPunteggi.Instances itis (exists pt in Instances suchthat (ident (s) eq
ident (pt.SchPunt)))
L3: forall pt in Instances itis (exists t in Trofeo.Instances suchthat (ident (pt.Tr) eq ident (t)))
L4: forall pt in Instances itis (exists s in SchemaPunteggi.Instances suchthat (ident
(pt.SchPunt) eq ident (s)))
L5: forall t in Trofeo.Instances itis (t.NumSch eq card (pt in Instances where (ident (pt.Tr) eq
ident (t))))
26
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
L6: forall t in SchemaPunteggi.Instances itis (s.NumTr eq card (pt in Instances where (ident
(pt.SchPunt) eq ident (s))))
Commento: questo context mette in relazione i trofei con i possibili schemi di punteggio che
potrebbero adottare. Le leggi L1 ed L2 ci assicurano che ogni istanza dell’object Trofeo è in
relazione con uno schema di punteggio (L1) e che ogni schema viene utilizzato in almeno un
trofeo (L2). Le due leggi seguenti implementano invece i vincoli di integritá referenziale,
verificando che tutti i trofei e schemi presenti in PuntinTr siamo presenti come istanze dei
rispettivi object (leggi L3 ed L4). Infine viene controllata la validitá degli attributi NumSch
dell’object Trofeo (che calcola quanti schemi di punteggio vengono utilizzati in ogni trofeo)
attraverso L5, e di NumTr dell’object SchemaPunteggi (che calcola quanti trofei utilizzano
quello schema) attraverso L6.
Anche qui la natura del context ci permette di asserire che ogni determinata coppia <trofeo schema> sará presente una sola volta in tutte le istanze di PuntinTr.
****
Context SocConTr
Tr: Trofeo mandatory
Soc: Societá mandatory
TotPunti: Punteggio mandatory
class attributes
SocMigliori: setof Societá
laws
L1: forall t in Trofeo.Instances itis (exists st in Instances suchthat (ident (t) eq ident (st.Tr)))
L2: forall st in Instances itis (exists t in Trofeo.Instances suchthat (ident (st.Tr) eq ident (t)))
L3: forall st in Instances itis (exists s in Societá.Instances suchthat (ident (st.Soc) eq ident
(s)))
L4: forall sm in SocMigliori itis (exists st1 in Instances suchthat ((ident (st.Soc) eq ident
(sm)) and (st1.TotPunti eq max (st2.TotPunti for st2 in Instances))))
Commento: questo context lega le societá con i trofei a cui hanno partecipato; L1 verifica che
ogni trofeo venga assegnato ad almeno una societá. Le due leggi seguenti (L2 ed L3) si
occupano dei vincoli di integritá referenziale, cioè garantiscono che ad ogni trofeo e societá
presenti qui corrispondano istanze degli object corrispondenti. L4 infine si occupa di descrivere
i requisiti che devono avere le societá classificate come migliori: sono quelle che hanno
conseguito in manifestazioni di tipo “trofeo” il punteggio piú alto rispetto alle altre.
Anche qui valgono le osservazioni svolte in precedenza: la natura del context ci garantisce che
ogni determinata coppia di istanze <trofeo - societá> sia presente una sola volta nell’insieme
delle possibili istanze di SocConTr.
****
INGEGNERIA DEL SOFTWARE
27
CAPITOLO 2 – MODELLO STATICO
Budget
integer
Soc
Man
SocOrgMan
Societá
Manifestazione
Soc
Man
Atl
PartecAtl
Atleta
ritirato
squalificato
Data
Atl
Da
t
ni
zio
ala
gn
Se
Punteggio
Gara
PuntIscr
PuntGara
Gar
Cartellino
Vers
Sticazzi
dimostrativ
Figura 6: Cartellino
28
INGEGNERIA DEL SOFTWARE
CAPITOLO 2 – MODELLO STATICO
annuale
biennale
triennale
quadriennale
Periodicitá
Trofeo
Manifestazione
Tr
integer
Societá
un
mP
Nu
Tr
NumTr
CodSchema
c
So
Punteggio
t
ListaPunt listof
To
tpu
SchemaPunteggi
Sch
P
Osservazioni
SocMigliori setof
SocConTr
nti
Punteggio
unt
PuntinTr
Vers
dimostrativ
string
Figura 7: Trofei - Punteggi
INGEGNERIA DEL SOFTWARE
29
3
Modello Funzionale
In questo capitolo vengono utilizzate le primitive view ed event per descrivere parte delle
funzioni che il sistema deve essere in grado di compiere.
Ovviamente si tratta di un insieme ridotto rispetto ad un sistema reale: lo scopo di questo
capitolo è di mostrare un esempio di utilizzo delle primitive di MDT.
3.1 Visualizzazioni: View
Visualizzazione di tutte le gare a cui ha partecipato un atleta nell’anno agonistico.
View GareAtleta (atl: Atleta)
from Cartellino
Ris: setof Gara
laws
L1: forall gar in Ris itis (exists c in Cartellino.Instances suchthat ((ident (gar) eq ident
(c.Gar)) and (ident (c.Atl) eq ident (atl))))
L2: forall c in Cartellino.Instances suchthat (ident (c.Atl) eq ident (atl)) itis (exists gar in
Ris suchthat (ident (gar) eq ident (c.Gar)))
Commento: L1 verifica che per ogni gara contenuta nell’insieme di gare del risultato esista
davvero un cartellino che lega quella gara all’atleta considerato. Al contrario, L2 verifica
che per ogni istanza di Cartellino dove l’atleta è quello considerato, la corrispondente gara
sia presente nel risultato.
Gestione gare di tiro con l’arco
INGEGNERIA DEL SOFTWARE
CAPITOLO 3 – MODELLO FUNZIONALE
Visualizzazione di tutte le manifestazioni patrocinate da una data federazione.
View FedManif (nomefed: string)
from FedOrgMan
Ris: setof Manifestazione
laws
L1: forall m in Ris itis (exists fom in FedOrgMan.Instances suchthat ((ident (m) eq ident
(fom.Man)) and (fom.Fed.Nome eq nomefed)))
L2: forall m in FedOrgMan.Instances suchthat (fom.Fed.Nome eq nomefed) itis (exists
m in Ris suchthat (ident (m) eq ident (fom.Man)))
Commento: analogamente al caso precedente, L1 controlla la presenza nei risultati
visualizzati di tutte le istanze di Manifestazione effettivamente sotto l’egida di una qualsiasi
federazione, mentre L2 ci assicura che tutte le istanze che soddisfano i requisiti vengano
effettivamente visualizzate.
Nei casi seguenti, data la similarità delle formulazioni, si ometterà questo tipo di commento
tranne in casi significativi.
Visualizzazione di tutte le gare che si sono svolte in una certa data.
View GaraGiorno (dat: Data)
from Gara
Ris: setof Gara
laws
L1: forall g in Ris itis (exists gar in Gara.Instances suchthat ((ident (g) eq ident (gar))
and (gar.Conc.Dataevento eq dat)))
Visualizzazione di tutti gli atleti attualmente tesserati presso una data società.
View AtlinSocietà (codice: integer)
from AtlinSoc
Ris: setof Atleta
laws
L1: forall atl in Ris itis (exists ats in AtlinSoc.Instances suchthat ((ident (atl) eq ident
(ats.Atl)) and (ats.Soc.CodSoc eq codice)))
L2: forall ats in AtlinSoc.Instances suchthat (ats.Soc.CodSoc eq codice) itis (exists atl in
Ris suchthat (ident (atl) eq ident (ats.Atl)))
INGEGNERIA DEL SOFTWARE
31
CAPITOLO 3 – MODELLO FUNZIONALE
Visualizzazione di tutti gli allenatori attualmente tesserati presso una data società.
View AllinSocietà (codice: integer)
from AllinSoc
Ris: setof Allenatore
laws
L1: forall all in Ris itis (exists als in AllinSoc.Instances suchthat ((ident (all) eq ident
(als.All)) and (als.Soc.CodSoc eq codice)))
L2: forall als in AllinSoc.Instances suchthat (als.Soc.CodSoc eq codice) itis (exists all in
Ris suchthat (ident (all) eq ident (als.All)))
Visualizzazione di tutte le manifestazioni che si svolgono in data odierna.
View ManifOggi
from Manifestazione
Ris: setof Manifestazione
laws
L1: let oggi= GET_TODAY_DATE()
L2: forall man in Ris itis (exists m in Manifestazione.Instances suchthat ((ident (man)
eq ident (m)) and (Data&Intervallo (d=oggi, i=m.Intervallo).Appartiene)))
Commento: per la disponibilità della data attuale viene invocata una funzione esterna che si
presuppone esistere nel sistema, cioè GET_TODAY_DATE().
Visualizzazione del numero di manifestazioni di tipo ufficiale a cui ha partecipato nei
precedenti anni agonistici un dato atleta.
View ManUffAtleta (atl: Atleta)
from PartecAtl
Ris: integer
laws
L1: Ris eq card (pat for pat in PartecAtl.Instances where ((ident (pat.Atl) eq ident (atl))
and (pat.Man.Denominazione eq ufficiale)))
32
INGEGNERIA DEL SOFTWARE
CAPITOLO 3 – MODELLO FUNZIONALE
3.2 Inserimenti: Event
Inserimento di un nuovo atleta in una società già esistente.
Event InsNuovoAtlinSoc
on Atleta, AtlinSoc, Società
CodFisc: string
Nome: string
Cognome: string
Sesso: (M, F)
Ind: Indirizzo
TelCasa: Telefono
TelUfficio: Telefono
TelCell: Telefono
DataNascita: Data
LuogoNascita: string
Ruolo: string
Curriculum: string
InizioAttività: Data
PuntMax: Punteggio
CodSoc: integer
precondition
L1: not exists atl in Atleta.Instances suchthat (atl.CodFisc eq CodFisc)
L2: not exists p in Persona.Instances suchthat (p.CodFisc eq CodFisc)
L3: exists soc in Società.Instances suchthat (soc.CodSoc eq CodSoc)
operation
{
atl.CodFisc= CodFisc
atl.Nome= Nome
atl.Cognome= Cognome
atl.Sesso= Sesso
atl.Ind= Ind
atl.TelCasa= TelCasa
atl.TelUfficio= TelUfficio
atl.TelCell= TelCell
atl.DataNascita= DataNascita
atl.LuogoNascita= LuogoNascita
atl.Ruolo= Ruolo
atl.Curriculum= Curriculum
atl.InizioAttività= InizioAttività
atl.Tesserato= true
atl.PuntMax= PuntMax
newinstances (atl) in Atleta
let a= at in Atleta.Instances suchthat (at.CodFisc eq CodFisc)
let s= so in Società.Instances suchthat (so.CodSoc eq CodSoc)
ats.Atl= a
INGEGNERIA DEL SOFTWARE
33
CAPITOLO 3 – MODELLO FUNZIONALE
ats.Soc= s
newinstances (ats) in AtlinSoc
}
Commento: in questo caso i controlli sono molto semplici, e l’inserimento di un nuovo
atleta non crea particolari problemi per quanto riguarda il rispetto delle condizioni di
integrità.
Inserimento di una nuova gara in un concentramento già esistente
Event InsGara
on Gara, Disciplina, Concentramento, Categoria, Manifestazione
Lunghezza: Distanza
Modalità: (apunti, torneo, girone)
CodMan: integer
Nprog: integer
Nome: string
Sesso: (M,F)
precondition
L1: exists d in Disciplina.Instances suchthat (d.Lunghezza eq Lunghezza and
d.Modalità eq Modalità)
L2: exists m in Manifestazione.Instances suchthat (c.CodMan eq CodMan)
L3: exists c in Concentramento.Instances suchthat (c.Man.CodMan eq CodMan and
c.Nprog eq Nprog)
L4: exists c in Categoria.Instances suchthat (c.Nome eq Nome and c.Sesso eq Sesso)
L5: not exists g in Gara.Instances suchthat (g.Disc.Lunghezza eq Lunghezza and
g.Disc.Modalità eq Modalità and g.Conc.Man.CodMan eq CodMan and g.Conc.Nprog
eq Nprog and g.Cat.Nome eq Nome and g.Cat.Sesso eq Sesso)
operation
{
let d= disc in Disciplina.Instances suchthat (disc.Lunghezza eq Lunghezza and
disc.Modalità eq Modalità)
let c= conc in Concentramento.Instances suchthat (conc.Man.CodMan eq CodMan and
conc.Nprog eq Nprog)
let ca= cat in Categoria.Instances suchthat (ca.Nome eq Nome and ca.Sesso eq Sesso)
g.Disc= d
g.Conc= c
g.Cat= ca
newinstances (g) in Gara
}
Commento: essendo all’interno di un context, è necessario controllare che l’immissione dei
dati in input che identificano gli oggetti sia corretta; inoltre vanno eseguiti i soliti controlli
di non esistenza della gara che si vuole inserire.
34
INGEGNERIA DEL SOFTWARE
CAPITOLO 3 – MODELLO FUNZIONALE
3.3 Aggiornamenti: Event
Aggiornamento percentuale dello stipendio di un atleta in una certa società.
Event AggStip
on Atleta, AtlinSoc, Società
CodFisc: string
CodSoc: integer
perc: integer
precondition
L1: exists atl in Atleta.Instances suchthat (atl.CodFisc eq CodFisc)
L2: exists soc in Società.Instances suchthat (soc.CodSoc eq CodSoc)
L3: exists ats in AtlinSoc.Instances suchthat (ats.Atl.CodFisc eq CodFisc and
ats.Soc.CodSoc eq CodSoc)
operation
{
let a= ats in AtlinSoc.Instances suchthat (ats.Atl.CodFisc eq CodFisc and
ats.Soc.CodSoc eq CodSoc)
ats.Stipendio ne null ⇒(
a.Stipendio= oldStipendio+perc*oldStipendio
update (a) in AtlinSoc
)
}
Commento: per aggiornare lo stipendio è necessario che lo stesso abbia un valore non nullo;
inoltre qui si illustra l’utilizzo degli attributi“old”, utilizzando anche semplici operazioni
aritmetiche.
Aggiornamento del numero di corsie e della lunghezza massima di un impianto.
Event AggLungh
on Impianto
Nome: string
Luogo: Indirizzo
Ncorsie: integer
LunghMax: Distanza
precondition
L1: exists i in Impianto.Instances suchthat (i.Nome eq Nome and i.Luogo eq Luogo)
INGEGNERIA DEL SOFTWARE
35
CAPITOLO 3 – MODELLO FUNZIONALE
operation
{
let imp= i in Impianto.Instances suchthat (i.Nome eq Nome and i.Luogo eq Luogo)
imp.LunghMax= ∼GET_MAX_IN (imp.oldLunghMax, LunghMax)
imp.Ncorsie= Ncorsie
update (imp) in Impianto
}
Commento: in questo caso si utilizza una funzione che deve essere già presente nel sistema,
la quale è in grado di calcolare il massimo valore intero tra tutti gli argomenti che le
vengono passati come parametri.
3.4 Eliminazioni: Event
Eliminazione di un atleta e delle sue prestazioni nell’anno agonistico corrente.
Event ElimPrestaz
on Atleta, AtlinSoc, Società, Cartellino
CodFisc: string
precondition
L1: exists atl in Atleta.Instances suchthat (atl.CodFisc eq CodFisc)
operation
{
let a= atl in Atleta.Instances suchthat (a.CodFisc eq CodFisc)
forall c in Cartellino.Instances suchthat (ident (c.Atl) eq ident (a)) itis (delinstances (as)
in Cartellino)
let as= ats in AtlinSoc.Instances suchthat (ident(ats.Atl) eq ident (a))
as ne null ⇒(
let s= soc in Società.Instances suchthat (ident (s) eq ident (as.Soc))
s.NumAtleti eq 1 ⇒delinstances (s) in Società
delinstances (as) in AtlinSoc
)
delinstances (a) in Atleta
}
Commento: per eliminare un atleta non è solo necessario cancellare la relativa istanza
dall’insieme delle istanze dell’oggetto Atleta; si deve porre attenzione al fatto che
quell’atleta, se è tesserato per l’anno agonistico corrente in una società, compare anche nel
context AtlinSoc, che deve essere quindi modificato di conseguenza. Inoltre la società
stessa, se ha solo quell’atleta iscritto, deve essere cancellata, poiché come vincolo si era
precedentemente stabilito che una società dovesse tesserare come minimo un atleta.
36
INGEGNERIA DEL SOFTWARE
CAPITOLO 3 – MODELLO FUNZIONALE
Eliminazione di uno schema di punteggi.
Event ElimSchPunt
on SchemaPunteggi, PuntinTr
CodSchema: integer
precondition
L1: exists sp in SchemaPunteggi.Instances suchthat (sp.CodSchema eq CodSchema)
operation
{
let sp= schpunt in SchemaPunteggi.Instances suchthat (schpunt.CodSchema eq
CodSchema)
forall pt in PuntinTr.Instances suchthat (ident (pt.SchPunt) eq ident (pt)) itis
(delinstances (pt) in PuntinTr)
delinstances (sp) in SchemaPunteggi
}
Commento: qui l’eliminazione di uno schema di punteggi comporta la modifica del context
PuntinTr, poiche per mantenere l’integrità dei dati è necessario eliminare la presenza
dell’oggetto appena cancellato.
INGEGNERIA DEL SOFTWARE
37