Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Corso di Laurea in Matema1ca Dipar9mento di Matema9ca e Fisica Sistemi per l’elaborazione delle informazioni 9. Principi di ingegneria del so9ware Dispense del corso IN530 a.a. 2014/2015 prof. Marco Liverani Scopo dell’ingegneria del so9ware • 
• 
L’ingegneria del soMware deﬁnisce modelli e metodologie per formalizzare il processo di progeAazione, realizzazione e manutenzione di un sistema informa9co In questo ambito si deﬁnisce un vero e proprio ciclo di vita del so9ware, nel tenta9vo di trasformare lo sviluppo soMware da un’aRvità ar9gianale verso un processo industriale –  in un’aRvità ar1gianale si possono raggiungere eleva9 livelli qualita9vi e di performance, ma questo è streTamente legato all’abilità dell’ar1giano; non sempre l’abilità può essere trasferita ad altri mediante un processo di formazione –  in un’aRvità industriale si cerca di raggiungere un livello di qualità e di performance adegua1 al posizionamento di mercato del prodoAo; qualità e performance sono oTenu9 mediante la deﬁnizione e la formalizzazione di processi e modalità di realizzazione di ciascuna aRvità necessaria nel ciclo di produzione; le aRvità sono misurabili e controllabili M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 1 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Ciclo di vita del so9ware • 
Un prodoTo soMware ha un suo ciclo di vita, ossia esistono diverse fasi successive durante il processo di realizzazione e manutenzione del soMware che vanno dal suo concepimento iniziale, ﬁno alla sua deﬁni9va dismissione 1.  Analisi preliminare – 
– 
Studio di faRbilità, deﬁnizione delle esigenze, deﬁnizione del contesto Deﬁnizione dei requisi9 2.  ProgeAazione del so9ware – 
– 
– 
Speciﬁche funzionali ed architeTurali del soMware Iden9ﬁcazione di librerie e componen9 soMware riusabili ProgeTazione delle componen9 del sistema soMware 3.  Realizzazione del so9ware – 
– 
Speciﬁche di deTaglio dei moduli Sviluppo dei moduli soMware, test unitario 4.  Test, collaudo e rilascio in produzione – 
– 
– 
Integrazione dei moduli e test unitari e di integrazione Collaudo e validazione del sistema integrato Rilascio, migrazione e caricamento dei da9, avvio in produzione 5.  Ges1one del sistema so9ware – 
– 
U9lizzo del soMware e manutenzione ordinaria, adegua9va, correRva (MAC), evolu9va (MEV) Rilascio di nuove release, ripetendo i passi 1–4 6.  Termine del ciclo di vita del so9ware – 
Messa fuori servizio del soMware, backup dei da9, migrazione da9 e servizi su nuovo soMware Prima fase: Analisi preliminare • 
ARvità principali: –  Studio di faRbilità, deﬁnizione dell’esigenza e della soluzione informa9ca, deﬁnizione dell’ambito del soMware, iden9ﬁcazione degli stakeholders (uten9, altri sistemi, ecc.) –  Deﬁnizione dei requisi1 • 
Output prodoR: –  Nota tecnica o documento di “vision”: contesto, esigenze e soluzioni, problema9che, disegno generale del sistema –  Iden9ﬁcazione delle risorse necessarie (umane e strumentali) e s9me di impegno –  Documento dei requisi9 (caraTeris9che del prodoTo soMware, cosa deve fare) • 
Figure professionali coinvolte: – 
– 
– 
– 
• 
Project Manager, Account Manager Analista SoMware Architect, System Architect Esperto del contesto di business Modalità opera9va: –  Interviste presso il cliente –  Analisi dei da9 e dei sistemi informa9ci preesisten9 –  Iden9ﬁcazione di soluzioni di mercato, open source o presen9 in azienda u9li al progeTo M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 2 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Seconda fase: ProgeAazione del so9ware • 
ARvità principali: –  Deﬁnizione delle speciﬁche graﬁco-‐funzionali del soMware –  Deﬁnizione delle speciﬁche di disegno architeTurale (architeTura ﬁsica, architeTura di rete, architeTura logica e delle componen9) –  ProgeTazione delle componen9 del sistema soMware • 
Output prodoR: –  Documento di speciﬁche funzionali, speciﬁche sui da9 –  Documento di disegno architeTurale, iden9ﬁcazione dei prodoR hardware e soMware e delle componen9 riusabili • 
Figure coinvolte: – 
– 
– 
– 
• 
Project Manager Analista SoMware Architect, System Architect Specialista di prodoTo Modalità opera9va: –  Lavoro in-‐house –  Use case diagram, sequence diagram, component diagram, en9ty/rela9onship diagram –  Studio di soluzioni di mercato, open source o presen9 in azienda Terza fase: Realizzazione del so9ware • 
• 
Avviene anche in concomitanza con la progeTazione (le due fasi possono essere concorren9, con uno sliTamento in avan9 della fase di realizzazione); si svolge in-‐house o presso il cliente a seconda degli strumen9 tecnologici impiega9 e dei vincoli contraTuali ARvità principali: –  Speciﬁche di deTaglio dei moduli soMware –  ProgeTazione dei moduli soMware (classi, funzioni, package e librerie) –  Sviluppo dei moduli soMware, test unitario • 
Output prodoR: –  Speciﬁche tecniche per lo sviluppo dei singoli moduli soMware (il deTaglio dipende dalla complessità del sistema e dal livello di coinvolgimento degli sviluppatori nella progeTazione) –  Speciﬁche che descrivono la struTura ad oggeR del modulo o il modello relazionale dei da9 –  SoMware documentato, soTo controllo di conﬁgurazione • 
Figure coinvolte: –  Project Manager –  SoMware Architect –  Analista-‐Programmatore, Programmatore • 
Modalità opera9va: – 
– 
– 
– 
– 
Lavoro in-‐house o presso il cliente Class diagram, ﬂow chart, documentazione del codice (es.: Javadoc) Uso di strumen9 di sviluppo in base al 9po di tecnologia scelta Uso di strumen9 di versioning e di tracciamento delle modiﬁche (controllo di conﬁgurazione) Test con9nuo dei moduli rilascia9 nel repository di progeTo (il soMware si compila?) M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 3 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Quarta fase: Test, collaudo e rilascio in produzione • 
• 
Avviene al termine dello sviluppo di un modulo soMware auto-‐consistente e cos9tuisce una milestone signiﬁca9va per il progeTo ARvità principali: – 
– 
– 
– 
Integrazione dei moduli e test unitari e di integrazione Test del sistema integrato Pianiﬁcazione del rilascio in produzione e predisposizione delle risorse necessarie (server, rete, ecc.) Rilascio e messa in produzione • 
Output prodoR: • 
Figure coinvolte: – 
– 
– 
– 
– 
– 
– 
– 
– 
– 
– 
– 
• 
Piano dei test e report di esecuzione dei test unitari e di integrazione Piano dei test e report di esecuzione dei test di sistema Piano di indirizzamento di rete Sistema funzionante nell’ambiente di produzione iden9ﬁcato insieme al cliente Manuale di conﬁgurazione e ges9one Manuale utente Piano di backup, piano di disaster recovery Istruzioni per il change management e il por6ng dei da9 Project Manager SoMware Architect Analista-‐Programmatore, Programmatore Sistemista Modalità opera9va: –  Lavoro presso il cliente nell’ambiente di produzione ﬁnale del prodoTo (in alcuni casi nell’ambiente di collaudo, supportando poi il cliente per il passaggio in ambiente di produzione) Quinta fase: Ges1one e manutenzione del sistema in produzione • 
Avviene dopo l’entrata in esercizio di almeno una delle componen9 soMware signiﬁca9ve; è un’aRvità priva di scadenze intermedie, ma con necessità di rendicontazione puntuale delle aRvità con una periodicità e un deTaglio deﬁni9 a livello contraTuale; la manutenzione correRva è soggeTa a SLA (service level agreement) deﬁni9 contraTualmente • 
ARvità principali: – 
– 
– 
• 
Output prodoR: – 
– 
– 
• 
Report di intervento Piano di formazione Documentazione delle modiﬁche soMware, con aggiornamento della documentazione Figure coinvolte: – 
– 
– 
– 
– 
• 
Supporto agli uten9 nell’u9lizzo del sistema e formazione, supporto agli amministratori nella ges9one del sistema Manutenzione ordinaria Manutenzione correRva ed evolu9va Project Manager Programmatore, Analista-‐Programmatore Sistemista Esperto di prodoTo/di sistema Operatore help desk Modalità opera9va: – 
– 
Lavoro presso il cliente nell’ambiente di produzione ﬁnale del prodoTo per le aRvità di assistenza, ges9one e formazione Lavoro in-‐house e presso il cliente per le aRvità di manutenzione correRva ed evolu9va M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 4 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Sesta fase: Termine del ciclo di vita del sistema • 
ARvità principali: – 
– 
Supporto agli amministratori per il trasferimento dei da9 Backup ﬁnale dei da9 e del soMware – 
Supporto al cliente per la deﬁnizione di un processo di passaggio dal vecchio al nuovo sistema • 
Output prodoR: • 
Figure coinvolte: – 
• 
Istruzioni per il change management e il por6ng dei da9 – 
Project Manager, Account Manager – 
Analista – 
– 
Sistemista Esperto di prodoTo/di sistema Modalità opera9va: – 
Lavoro presso il cliente nell’ambiente di produzione ﬁnale del prodoTo, in collaborazione con il team che si occupa di implementare il nuovo sistema informa9co AspeQ rilevan1 per la progeAazione del prodoAo so9ware • 
A monte del processo di progeTazione e sviluppo del soMware, devono essere presi in esame ed analizza9 aTentamente alcuni aspeR che condizionano il prodoTo soMware stesso –  Scopo del progeAo •  Contesto di business in cui si opera •  ObieRvi del progeTo –  Cliente, commiAente ed altri aAori •  Descrizione del cliente, ossia colui che ci pagherà per il lavoro svolto •  Descrizione del commiTente, ossia colui che ha richiesto il lavoro •  Altri soggeR coinvol9: sponsor, altre aziende, esper9 di vario genere coinvol9 dal cliente o dal commiTente –  Uten1 del prodoAo so9ware •  Uten9 ﬁnali, possibilmente raggruppa9 per ruolo nell’ambito del contesto di business e iden9ﬁcando la competenza nel seTore di business e in ambito informa9co •  Priorità degli uten9 nella valutazione del nostro lavoro •  Partecipazione degli uten9 al progeTo (deﬁnizione dei requisi9, fornitura di informazioni cri9che per la riuscita del progeTo, test, approvazione, ecc.) •  Uten9 addeR alla ges9one del sistema (sistemis9, e altri addeR) M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 5 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 AspeQ rilevan1 per la progeAazione del prodoAo so9ware –  Vincoli obbligatori Vincoli alla soluzione (vincoli tecnici sulle caraTeris9che generali o sui prodoR da usare o non usare) Ambiente per l’implementazione (piaTaforma di base, framework o altri middleware da usare) Applicazioni da integrare (altri sistemi preesisten9 con cui il nostro soMware si deve integrare) ProdoR di mercato o open source da u9lizzare Ambiente di lavoro in cui è impiegato il prodoTo (descrizione tecnica o anche logis9ca o “culturale”) Vincoli temporali (vincoli di tempo dovu9 a faTori esterni o opportunità che devono essere colte entro una determinata ﬁnestra temporale) •  Vincoli di budget (la pianiﬁcazione delle aRvità, le risorse e il tempo impiegato devono essere deﬁni9 tenendo conto di questo vincolo) • 
• 
• 
• 
• 
• 
–  Convenzioni sui nomi •  Deﬁnizioni e acronimi u9lizza9 nell’ambito del progeTo –  FaQ rilevan1 e altre assunzioni •  Fa8: faTori che hanno impaTo sul sistema, pur non cos9tuendo dei vincoli o dei requisi9 (regole di business, processi esterni al sistema, ma che possono avere impaTo su di esso in determinate condizioni, ecc.) •  Assunzioni: ipotesi verosimili che vengono assunte come veri9ere e su cui si basano alcune delle scelte di progeTo; devono essere condivise con il cliente e con il commiTente e non possono contraddire la realtà oggeRva (es.: mi aspeTo che tuR gli uten9 abbiano un PC con certe caraTeris9che; mi aspeTo che i device mobili possano essere con9nuamente connessi alla rete, ecc.) AspeQ rilevan1 per la progeAazione del prodoAo so9ware –  Ambito in cui viene eseguito il progeAo •  La situazione aTuale (come fanno ora, senza il nostro prodoTo?) •  Contesto in cui si inserisce il prodoTo soMware •  Business event che devono essere implementa9/supporta9 dal prodoTo soMware –  Ambito del prodoAo so9ware •  Limi9 di competenza del prodoTo soMware (ﬁno a dove deve supportare il processo di business e cosa non deve fare) •  Use case (casi d’uso) del prodoTo soMware, ossia azioni auto-‐consisten9 da parte degli uten9 o di altri sistemi che il prodoTo deve implementare o supportare M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 6 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Deﬁnizione dei requisi1 • 
I requisi1 del prodoTo descrivono cosa il sistema deve oﬀrire (dominio del problema) e non come il sistema deve essere sviluppato (dominio della soluzione) • 
La correAa deﬁnizione dei requisi1 è una delle aRvità che determinano la riuscita di un progeAo e che talvolta si tende erroneamente a soTovalutare Applicarsi nella deﬁnizione dei requisi9 è fondamentale per darsi la possibilità di analizzare a fondo il contesto e le problema9che organizza9ve e tecniche con cui ci si dovrà misurare nell’ambito del progeTo I modelli di ciclo di vita del soMware moderni hanno abbandonato l’idea che sia possibile iden9ﬁcare i requisi9 di un sistema soMware a priori: tendono a privilegiare approcci itera1vi • 
• 
• 
I requisi1 sono l’elemento di riscontro per veriﬁcare se il prodoTo soMware è un prodoAo di qualità; spesso i requisi9 del prodoTo e la veriﬁca del recepimento dei requisi9 sono un aspeTo rilevante del contraTo tra il commiTente e l’azienda che sviluppa il soMware • 
Esistono diversi 9pi di requisi9 che possono essere deﬁni9 anche in momen9 diversi nell’ambito di un progeTo soMware: – 
– 
– 
– 
– 
– 
Requisi1 funzionali: cosa fa il sistema, come deve interagire con gli uten9 o con altri sistemi Requisi1 non funzionali: da9, performance, aﬃdabilità, ecc. Requisi1 architeAurali: prodoR/piaTaforme che si devono o non si devono usare, struTura del sistema, ecc. Requisi1 di progeAo: tempo, budget, risorse, logis9ca, ecc. Driver di progeAo: obieRvi organizza9vi, poli9ci, opportunità di mercato, ecc. Altri aspeR che caraTerizzano il progeTo Deﬁnizione dei requisi1 • 
• 
I requisi9 devono essere riporta9 su uno o più documen9 e devono poter essere iden9ﬁca9 chiaramente e in modo sinte9co Esempio di schema per la deﬁnizione di un requisito: ID del requisito: codice iden9ﬁca9vo univoco del requisito Tipo di requisito: funzionale, non funzionale, ecc. Business event o Use case che richiede il requisito Descrizione: breve descrizione del requisito Mo1vazione: gius9ﬁcazione del requisito (cosa succede se non viene implementato?) Criterio di veriﬁca: descrizione del criterio con cui si potrà veriﬁcare se il requisito è soddisfaTo oppure no –  Priorità: priorità del requisito rispeTo ad altri (indispensabile o superﬂuo? Lo ha richiesto esplicitamente il cliente o è solo un modo per migliorare il sistema?) –  Dipendenze: iden9ﬁca9vi di altri requisi9 da cui dipende questo requisito –  Data/versione: data di creazione o modiﬁca del requisito – 
– 
– 
– 
– 
– 
• 
• 
• 
I requisi9 e le dipendenze tra i requisi9 cos9tuiscono un grafo orientato (aciclico!) di cui si deve tenere conto, quando si intende modiﬁcare uno dei requisi9 del sistema Si deve poter tracciare i requisi9 in ogni componente del progeTo: codice, casi di test, … La tracciabilità è un aspeTo di qualità di un progeTo soMware fondamentale per molte aRvità: l’analisi degli impaR di un cambiamento di requisi9, la veriﬁca della correTezza di un’implementazione, il test e il regression test M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 7 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Deﬁnizione dei requisi1 • 
Requisi1 funzionali e sui da1 1.  Requisi9 funzionali (cosa deve fare il sistema?) 2.  Requisi9 graﬁco-‐funzionali (come deve presentarsi o deve reagire il sistema? Quale s9le deve adoTare? Come viene garan9ta la coerenza dell’interfaccia utente?) 3.  Requisi9 sui da9 (un diagramma E/R, ma anche altri requisi9 rela9vi al ciclo di vita dei da9, alla loro persistenza, alla quan9tà, alla codiﬁca, ecc.) • 
Requisi1 sull’usabilità 1.  Requisi9 sulla facilità d’uso 2.  Requisi9 per l’accesso di uten9 con disabilità o in condizioni logis9che disagevoli 3.  Requisi9 per l’internazionalizzazione del prodoTo (prodoTo mul9lingua) • 
Requisi1 sulle performance 1.  Requisi9 sulla rapidità di risposta e sulla latenza del sistema 2.  Requisi9 di precisione e accuratezza (precisione numerica, precisione nelle conversioni di da9, ecc.) 3.  Aﬃdabilità e disponibilità del sistema (quali livelli di servizio deve reggere? Per quanto tempo il sistema può non essere disponibile?) 4.  Fault-‐tolerance (condizioni di errore a cui il sistema deve poter resistere) 5.  Requisi9 di capacità (capacità di memorizzazione, capacità di servire un elevato numero di client contemporanei, ecc.) 6.  Requisi9 di scalabilità (capacità del sistema di crescere orizzontalmente o ver9calmente per venire incontro alla crescita delle esigenze del cliente) Deﬁnizione dei requisi1 • 
Requisi1 sulla sicurezza 1.  Requisi9 sul controllo degli accessi (chi è autorizzato ad accedere, a quali condizioni, con quali metodi di iden9ﬁcazione, ecc.) 2.  Requisi9 sull’integrità dei da9 3.  Requisi9 sulla privacy (quali da9 non devono essere memorizza9, chi può accedere a determina9 da9, ecc.) 4.  Requisi9 di audi9ng (quali even9 devono essere traccia9 nei log del sistema, secondo quale modalità tecnica, ecc.) • 
Requisi1 legali 1.  Requisi9 sulle norma9ve a cui deve aderire il sistema (es.: ges9one delle utenze come stabilito dal DPR 196/2003) 2.  Requisi9 sugli standard da adoTare (formato dei da9, protocolli, ecc.) • 
Requisi1 sulla documentazione e sulla formazione 1.  Manuali e documen9 da produrre, lingua della documentazione, formato della documentazione 2.  Requisi9 sui sistemi di aiuto on-‐line per l’uso del sistema, requisi9 sul materiale didaRco a supporto della formazione M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 8 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Deﬁnizione dell’architeAura • 
La descrizione dell’architeAura è un aspeTo essenziale nella progeTazione del soMware, dal momento che ciò che viene prodoTo è spesso un sistema, formato da diverse componen9 che interagiscono fra di loro • 
I requisi9 che hanno un impaTo direTo sull’architeTura del sistema e che quindi concorrono alla sua deﬁnizione, possono essere raggruppa9 sulla base della seguente classiﬁcazione “FURPS”: – 
– 
– 
– 
– 
Funzionalità: il sistema deve essere capace di fornire determinate funzioni Usabilità: il sistema deve essere facilmente fruibile dall’utente ﬁnale Aﬃdabilità (Reliability): il sistema deve ges9re e possibilmente “resistere” ad errori e crash Prestazioni: il sistema deve avere performance adeguate Supportabilità: il sistema deve essere tale da consen9re una correTa ges9one e manutenzione Deﬁnizione dell’architeAura • 
Per descrivere l’architeTura del sistema è necessario adoTare “viste” diverse, fra loro complementari • 
Vista logica –  organizzazione conceTuale del soMware in termini di stra9, soTosistemi, package, framework, classi e interfacce più importan9; in questa “vista” si riassumono anche le funzionalità oﬀerte dalle componen9 soMware e dai soTosistemi –  Può mostrare gli scenari d’uso più importan9 o più cri9ci al ﬁne di meTere in evidenza il ruolo di ciascuna componente logica del soMware • 
Vista dei processi • 
Vista di deployment • 
Vista sui da1 –  Descrive il modello del progeTo e l’organizzazione in processi –  Descrive il livello ﬁsico con cui sarà pubblicato in ambiente di produzione il sistema soMware –  Descrive il modello di rappresentazione delle informazioni ges9te dal sistema ed i ﬂussi di trasmissione • 
Vista sulla sicurezza –  Auten9cazione degli uten9, single sign-‐on, modello autorizza9vo, cifratura, ecc. M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 9 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 UML: Uniﬁed Modeling Language • 
• 
• 
• 
UML è un formalismo graﬁco per descrivere e documentare l’architeAura e le funzionalità di un sistema; è un linguaggio di modellazione e speciﬁca basato sul paradigma object-‐
oriented UML svolge una funzione di “lingua franca” nella comunità della progeTazione e programmazione a oggeR Il modello è struTurato secondo un insieme di viste che rappresentano diversi aspeR del sistema modellato (funzionamento, struTura, comportamento, ecc.) UML consente di descrivere un sistema secondo tre aspeR principali: –  il modello funzionale (diagrammi dei casi d'uso) –  il modello a oggeQ (diagrammi delle classi) –  il modello dinamico (diagrammi di sequenza) • 
• 
• 
La documentazione del progeTo è uno strumento che obbliga ad una aTenta riﬂessione u9le per evitare di compiere errori nella successiva fase di realizzazione UML oﬀre uno strumento di documentazione vicino e compa9bile con gli aspeR più tecnici di realizzazione del soMware; adoTa inoltre un formalismo noto e comune; per ques9 due mo9vi principali ha avuto un successo notevole UML viene usato per descrivere e documentare aspeR assai complessi ed astraR, per cui non è di per sé suﬃciente: va integrato con documentazione più descriRva o di maggiore deTaglio su alcuni aspeR UML, modello funzionale: use case diagrams • 
• 
Il caso d’uso (use case) è la descrizione di uno scenario elementare di u9lizzo del sistema La speciﬁca di un caso d’uso dovrebbe includere – 
– 
– 
– 
• 
un nome, con cui iden9ﬁcare il caso d’uso gli aAori principali e secondari, ossia i soggeR (umani o tecnologici) che partecipano allo scenario un obieQvo, il mo9vo per cui gli aTori principali avviano il caso d’uso la precondizione nella quale è eseguibile il caso d’uso Lo use case diagram di UML fornisce una rappresentazione del caso d’uso Sistema
Sistema Autenticazione
ATore Utente
Use Case <extends>
chiede OTP
Autenticazione
forte
M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni Amministratore
10 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 UML, modello a oggeQ: class diagrams • 
• 
• 
Nella programmazione object oriented la “classe” è il conceTo fondamentale su cui si ar9cola l’intero programma: descrivere correTamente le classi con i loro metodi e aTribu9 e le relazioni esisten9 tra oggeR di classi diverse è di cruciale importanza I class diagram forniscono una visione sta1ca delle classi presen9 in un progeTo soMware object oriented Il class diagram del linguaggio UML rappresenta le classi come box contenen9 gli aTribu9 della classe e collegate fra loro da linee che rappresentano i diversi 9pi di relazione esisten9 tra le classi –  la molteplicità è un 9po di associazione in cui si mostra il numero di oggeR appartenen9 ad una classe che interagisce con il numero di oggeR della classe associata –  l’ereditarietà mostra le proprietà che vengono condivise tra classe padre e classe ﬁglio UML, modello dinamico: sequence diagram • 
• 
• 
Un diagramma di sequenza (sequence diagram) descrive uno scenario, evidenziando la sequenza di azioni svolte dagli aTori sul sistema (o messaggi scambia9 tra gli aTori e il sistema) Uno scenario è una determinata sequenza di azioni in cui tuTe le scelte sono state già eﬀeTuate; in pra9ca nel diagramma non compaiono scelte, né ﬂussi alterna9vi Normalmente da ogni ac6vity diagram sono deriva9 uno o più sequence diagram –  ad esempio se un ac9vity diagram descrive due ﬂussi di azioni alterna9vi, se ne possono ricavare due scenari, e quindi due sequence diagram alterna9vi Studente
Sistema ESSE3
Docente
linea della vita aTore Pubblica esame
Iscrizione esame
Invia notifica
Consulta iscrizioni
Registra voti
aRvazione azioni o messaggi Firma verbale
Consulta libretto esami
M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 11 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 UML, modello dinamico: ac1vity diagram • 
• 
• 
Rappresenta i passi di un processo implementato da un sistema per realizzare le sue funzionalità; è un formalismo simile a quello dei diagrammi di ﬂusso, ma può essere impiegato in contes9 di minor deTaglio, più astraR In UML 2.x il formalismo degli ac-vity diagram è stato decisioni ridisegnato per seguire quello delle Re9 di Petri In un ac6vity diagram sono evidenzia9 i seguen9 elemen9: sì
–  azioni –  decisioni (che portano a dividere il processo in più ﬂussi dis9n9) –  pun9 di separazione del processo o pun9 di ricongiungimento –  pun9 di avvio e di conclusione del processo –  possono essere anche evidenzia9 gli aTori responsabili di una determinata azione (creando una ibridazione con i sequence diagram) aRvità cerca
prodotto
gestisci
carrello
utente registrato?
no
autenticaz.
utente
registraz.
utente
acquisto
gestione
ordine
processi concorren9 consultaz.
ordine
consegna
Altri diagrammi • 
Business Process Model Nota6on (BPMN) –  rappresentazione e descrizione di un processo di business (workﬂow) • 
Data Flow Diagram –  rappresentazione del ﬂusso delle informazioni tra i diversi moduli di un sistema informa9co che si scambiano da9 aTraverso aree di memoria comuni, archivi condivisi, protocolli di rete o meccanismi di interprocess communica9on • 
State Diagram –  rappresenta gli sta9 in cui può trovarsi un sistema e le transizioni di stato lecite (o ges9te/
implementate dal sistema stesso) che consentono il passaggio da uno stato ad un altro M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 12 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Ges1one della conﬁgurazione • 
• 
• 
Il conﬁgura1on management supporta la ges9one ed il controllo degli elemen9 che compongono un sistema soMware La ges9one di tali elemen9 (conﬁgura-on items) è aﬃdata ad un database (repository di conﬁgurazione) in cui sono censi9 gli oggeR soTopos9 a controllo di conﬁgurazione Nell'ambito del conﬁgura-on management vengono ges99 gli input/output direTamente o indireTamente lega9 alla costruzione di un prodoTo soMware –  Si archiviano in modo controllato le varie versioni del codice sorgente sviluppato, i documen9, i test, i da9 di conﬁgurazione, ecc. • 
• 
Una delle funzioni svolte da un sistema di controllo della conﬁgurazione (CMS, conﬁgura6on management system) è quella di correlare tra loro i vari oggeR archivia9 rela9vamente alle diverse versioni o ai diversi branch di un prodoTo soMware Versione: è un soToinsieme dei conﬁgura6on item che deﬁnisce completamente una release del prodoTo soMware; –  possono coesistere più versioni successive dello stesso prodoTo (manutenzione correRva ed evolu9va di versioni preceden9 a quella corrente, con modiﬁche che sono recepite dalle versioni successive) –  uno stesso conﬁgura9on item può essere presente in una o più versioni del prodoTo • 
Branch: è una copia di una versione del prodoTo, in modo da portare avan9 versioni diverse e indipenden9 del prodoTo (le modiﬁche su un branch non impaTano sugli altri) Ges1one della conﬁgurazione • 
Un prodoTo CMS è un soMware che ges9sce un archivio di ﬁle e oﬀre un protocollo di comunicazione per eseguire delle operazioni sul repository del prodoTo soMware –  check out: si estraggono dal repository i conﬁgura6on item e se ne produce una copia locale su cui l’utente (programmatore) può lavorare –  update: si aggiorna il progeTo locale con eventuali modiﬁche occorse sui conﬁgura6on item presen9 sul repository di progeTo –  add, delete, move, copy: si aggiunge o si modiﬁca la conﬁgurazione del progeTo con elemen9 presen9 nella conﬁgurazione locale (nuovi ﬁle, eliminazione di ﬁle, ecc.) –  commit: si carica sul repository la copia locale del progeTo (o di singoli conﬁgura6on item) –  lock: si blocca sul repository la modiﬁca ad un conﬁgura6on item che è in lavorazione da parte di un utente (programmatore) sul proprio repository locale • 
• 
• 
Il soMware CMS rileva eventuali conﬂiQ (es.: aggiornamen9 diversi da parte di due uten9 allo stesso conﬁgura6on item) e aiuta gli uten9 del gruppo di lavoro a ges9rli Il soMware CMS ad ogni aggiornamento di un conﬁgura6on item ne crea una nuova versione, mantenendo in archivio le vecchie versioni (versioning) Il soMware CMS ges9sce il controllo degli accessi degli uten1 ai repository dei diversi prodoR soMware M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 13 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Ges1one della conﬁgurazione • 
Alcuni prodoR soMware di conﬁgura9on management –  CVS, concurrent version system (open source) –  SVN, subversions, nato come evoluzione di CVS (open source) –  GIT, realizzato da Linus Torvalds per il controllo di conﬁgurazione del kernel di Linux (open source) –  IBM Ra1onal ClearCase, componente della suite di tool di progeTazione e sviluppo soMware IBM Ra9onal (proprietario) –  Microso9 Visual SourceSafe, componente della suite di tool di sviluppo soMware MicrosoM Visual Studio (proprietario) Sistemi di Ges1one per la Qualità • 
Terminologia: –  ProdoAo: output di un processo di lavorazione –  Processo di lavorazione: un progeAo per realizzare un sistema informa9co, un insieme di aRvità per realizzare un prodoAo, un insieme di aRvità per erogare un servizio, ecc. –  Requisi1: caraAeris1che che ci si aspeTa debba avere il prodoTo –  ProdoAo di Qualità: ProdoAo che rispeTa in pieno ai requisi1 • 
Sistemi di Ges1one per la Qualità –  Complesso di procedure, regole e strumen1 (tecnici e documentali) di cui un’organizzazione si dota per ges9re il processo produRvo in modo tale da realizzare prodoR di qualità –  Si basano su alcuni principi fondamentali: •  DOCUMENTAZIONE: descrizione esplicita delle informazioni necessarie per la realizzazione del prodoTo •  TRACCIABILITÀ: iden9ﬁcare con certezza lo stato del processo, delle aRvità e delle componen9 in lavorazione •  IDENTIFICAZIONE: possibilità di iden9ﬁcare con certezza ogni elemento che entra a far parte del processo produRvo, rendendo eviden9 le modiﬁche e lo stato di aggiornamento di ciascun elemento •  RIPRODUCIBILITÀ: possibilità di ripetere un processo (è possibile se è documentato) •  MISURAZIONE: ogni aRvità deve essere caraTerizzata da un insieme di indicatori che consentano di “misurare la qualità” • 
Norma9va internazionale che deﬁnisce i requisi9 di un buon sistema di ges9one per la qualità: UNI EN ISO 9001:2000 (ul9ma revisione: novembre 2008) M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 14 Università degli Studi Roma Tre -‐ Corso di Laurea in Matema9ca a.a. 2014/2015 Sistemi di Ges1one per la Qualità • 
Un Sistema di Ges9one per la Qualità cer9ﬁcato secondo la norma ISO 9001 è caraTerizzato da un insieme di documen9: –  Poli1ca per la qualità: documento con cui il top management dell’azienda dichiara la mo9vazione ad adoTare il sistema e le linee guida di alto livello per la deﬁnizione del sistema –  Organigramma funzionale e nominale: è il documento in cui si dichiara la struTura organizza9va e i ruoli –  Manuale della qualità: documento che descrive macroscopicamente i processi presen9 nell’organizzazione e i workﬂow che determinano i contribu9 delle diverse ﬁgure professionali –  Procedure ges1onali: ogni processo macroscopico viene descriTo in una procedura che evidenzia gli step e le responsabilità e indica in che modo il processo viene documentato (es.: processo selezione del personale, processo acquisto, processo progeTazione e sviluppo soMware, ecc.) –  Istruzioni opera1ve: servono per descrivere in deTaglio speciﬁche operazioni svolte nell’ambito di un processo (es.: ges9one della corrispondenza in entrata o in uscita, creazione di un nuovo ambiente di sviluppo per un progeTo soMware, ecc.) –  Modulis1ca: sono documen9 u9li per le “registrazioni della qualità” e per la rilevazione degli indicatori di performance • 
Il sistema di ges9one per la Qualità si applica ad ogni progeTo di sviluppo soMware • 
Per progeR par9colarmente rilevan9 è possibile deﬁnire un Piano della Qualità speciﬁco per un determinato progeTo • 
È importante deﬁnire una codiﬁca univoca per iden1ﬁcare i documen9 prodoR nell’ambito del progeTo 1965 – 2015: alcune milestone degli ul6mi 50 anni di informa6ca Alcuni computer che negli ul6mi 50 anni hanno segnato dei passi in avan6 signiﬁca6vi nell’evoluzione della tecnologia informa6ca M. Liverani -‐ Dispense del corso IN530 -‐ Sistemi per l'elaborazione delle informazioni 15