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