Appunti Ingegneria del software

Indice
RUP........................................................................................................................................................................... 3
Prospettiva statica: attività del RUP ..................................................................................................................... 3
Prospettiva dinamica: le fasi del RUP ................................................................................................................... 3
Distribuzione delle attività nelle fasi .................................................................................................................... 4
Buone pratiche RUP ............................................................................................................................................. 6
I modelli................................................................................................................................................................ 6
Processo centrato sull’architettura ...................................................................................................................... 8
Approccio guidato dai rischi ................................................................................................................................. 8
Documento di visione del sistema .......................................................................................................................... 10
Studio di fattibilità .................................................................................................................................................. 13
Analisi del contesto ................................................................................................................................................ 14
Use-cases ............................................................................................................................................................... 15
Attori .................................................................................................................................................................. 15
Definire e disegnare gli use-cases ...................................................................................................................... 16
Relazioni tra use-cases ....................................................................................................................................... 16
Use Case Overview Diagrams ............................................................................................................................. 18
Modellare il flusso di lavoro del sistema – Diagramma di attività .......................................................................... 19
Oggetti................................................................................................................................................................ 21
Segnali ................................................................................................................................................................ 21
Partizioni ............................................................................................................................................................ 22
Connettori .......................................................................................................................................................... 22
Regioni di espansione......................................................................................................................................... 22
Analisi nomi-verbi .................................................................................................................................................. 23
Schede CRC............................................................................................................................................................. 25
Classi di analisi – Entity -Control-Boundary Pattern ............................................................................................... 27
Diagramma delle classi (di progetto) ...................................................................................................................... 30
Visibilità .............................................................................................................................................................. 30
Attributi – lo stato della classe ........................................................................................................................... 31
Operazioni – il comportamento della classe ...................................................................................................... 32
 Componenti statici di una classe ........................................................................................................................ 32
Relazioni tra classi .............................................................................................................................................. 32
Vincoli................................................................................................................................................................. 34
Classi astratte ..................................................................................................................................................... 34
Interfacce ........................................................................................................................................................... 35
Templates (o classi parametriche o generiche) .................................................................................................. 35
Diagramma dei packages ....................................................................................................................................... 37
Diagramma di sequenza ......................................................................................................................................... 39
Eventi, segnali e messaggi .................................................................................................................................. 39
Frammenti di sequenza ...................................................................................................................................... 40
Esempio .............................................................................................................................................................. 43
Piano dei test ......................................................................................................................................................... 46
Cosa chiedersi per redigere il piano ................................................................................................................... 46
Linee guida ......................................................................................................................................................... 46
Checklist ............................................................................................................................................................. 48
Tipi di test ........................................................................................................................................................... 49
Per approfondire ................................................................................................................................................ 50
Gestione dei rischi e garanzia di qualità ................................................................................................................. 51
Processo di gestione dei rischi............................................................................................................................ 51
Principi di Software Quality Assurance ............................................................................................................... 51
Gestione della configurazione del software (SCM) ............................................................................................. 52
Gestione dei rischi e della qualità ....................................................................................................................... 53
Link utili .............................................................................................................................................................. 53

Schema di Giovanni Ficarra basato sugli argomenti del corso di Ingegneria del software del professor Bottoni,
realizzato usando le sue dispense, i libri Software engineering e Learning UML e risorse online indicate per ogni
paragrafo.
Per contattarmi potete scrivere a giovannificarra95@gmail.com.
RUP
• Caratteristiche:
o Processo guidato dai casi d’uso
o Processo centrato sull’architettura
o Approccio guidato dai rischi

Prospettiva statica: attività del RUP

1. Business modelling: si modellano i processi di business con casi di business
2. Requirements: si identificano gli attori che interagiscono col sistema e si sviluppano casi d’uso per
modellare i requisiti di sistema
3. Analysis and design: si crea e documenta il modello di progetto, usando modelli di architettura,
componenti, oggetti e sequenza
4. Implementazione: le componenti del sistema sono implementate e strutturate in sotto-sistemi di
implementazione, eventualmente usando la generazione automatica del codice dal modello
5. Test: processo iterativo congiunto all’implementazione, finita questa si esegue un test di sistema
6. Deployment: rilascio del prodotto, distribuzione agli utenti e installazione nel loro ambiente di lavoro
7. Configuration and change management: flusso di lavoro di supporto per gestire cambiamenti del
sistema
8. Project management: flusso di lavoro di supporto per gestire lo sviluppo del sistema
9. Environment: si rendono disponibili gli strumenti software appropriati alla squadra di sviluppo del
software

Prospettiva dinamica: le fasi del RUP

1. Inception: stabilire un caso di business per il sistema
2. Elaboration: sviluppare e comprendere il dominio del problema e l’architettura del sistema
3. Construction: progettazione, programmazione e test del sistema
4. Transition: stabilire il sistema nell’ambiente di esecuzione

• Nelle prime due fasi si definisce l’ambito del progetto, si eliminano i rischi critici e si crea l’architettura
di base, le iterazioni producono raffinamenti
• Nella terza le iterazioni producono incrementi
• Il progetto è composto da mini-progetti, ognuno realizzato in un’iterazione
• Ogni iterazione prevede flussi di lavoro
Distribuzione delle attività nelle fasi

• Inception:
o Focus:
▪ Requirements: stabilire caso di business e contesto, raccogliere i requisiti principali
▪ Analysis: stabilire la fattibilità
▪ Design: progettare una prova di concetto o prototipi tecnici
▪ Implementation: costruire la prova di concetto o i prototipi tecnici
▪ Test: -
o Obiettivi:
▪ Stabilire la fattibilità del progetto
▪ Creare un caso di business
▪ Definire contesto del sistema e requisiti chiave
▪ Identificare i rischi critici
o Milestone:
▪ Ambito del sistema definito
▪ Requisiti chiave definiti e concordati con gli stakeholder
▪ Visione architetturale schematizzata
▪ Rischi valutati
▪ Caso di business creato
▪ Fattibilità confermata
▪ Stakeholder d’accordo con gli obiettivi del progetto
o Criterio essenziale: adeguatezza
• Elaboration:
o Focus:
▪ Requirements: rifinire il contesto del sistema e i requisiti
▪ Analysis: stabilire cosa costruire
▪ Design: creare una base stabile per l’architettura
▪ Implementation: costruire la base dell’architettura
▪ Test: testare la base dell’architettura
o Obiettivi:
▪ Creare una base dell’architettura eseguibile
▪ Rifinire i rischi e definire gli attributi di qualità
▪ Catturare gli use case dell’80% dei requisiti funzionali
▪ Creare un piano abbastanza dettagliato per la fase di construction
▪ Formulare un’offerta che includa risorse, tempo, strumentazione, staff, costo
o Milestone:
▪ Creata una base resistente, robusta ed eseguibile per l’architettura
▪ Aggiornata la valutazione dei rischi
▪ Creato un piano di progetto che permetta di formulare un’offerta realistica
▪ Verificato il caso di business rispetto al piano
▪ Stakeholder d’accordo su continuare
o Criterio essenziale: realizzabilità
• Construction:
o Focus:
▪ Requirements: scoprire requisiti mancanti
▪ Analysis: finire il modello di analisi
▪ Design: finire il modello di design
▪ Implementation: costruire la Capacità Operativa Iniziale
▪ Test: testare la Capacità Operativa Iniziale
o Obiettivi:
▪ Completare l’identificazione, la descrizione e la realizzazione degli use case
▪ Finire analisi, design, implementazione e test
▪ Mantenere l’integrità dell’architettura del sistema
▪ Revisionare la valutazione dei rischi
o Milestone:
▪ Prodotto pronto per il beta testing nell’ambiente dell’utente
o Criterio essenziale: operazionalità iniziale
• Transition:
o Focus:
▪ Requirements: -
▪ Analysis: -
▪ Design: modificare il design se nel beta testing emergono problemi
▪ Implementation: adattare il software all’ambiente dell’utente e correggere bug scoperti
nel beta testing
▪ Test: eseguire il beta testing e il test di accettazione nell’ambiente dell’utente
 o Obiettivi:
▪ Correggere i difetti
▪ Preparare l’ambiente dell’utente per il nuovo software ed adattare il software per
operare in quell’ambiente
▪ Modificare il software se emergono problemi non previsti
▪ Creare manuali utente e altra documentazione
▪ Fornire consulenza al cliente
▪ Condurre revisioni post progetto
o Milestone:
▪ Completati beta testing, test di accettazione e correzione dei difetti
▪ Prodotto rilasciato agli utenti
o Criterio essenziale: operazionalità finale

Buone pratiche RUP

• Sviluppare software iterativamente
• Gestire requisiti tramite use case e Supplementary Requirement Specification
• Usare architetture basate su componenti
• Modellare il software visivamente
• Verificare la qualità del software
• Controllare i cambiamenti del software

I modelli
• Modello degli use case:
o Formato da attori e casi d’uso:
▪ Gli attori rappresentano i tipi di utenti, definiscono l’ambiente del sistema
▪ I casi d’uso rappresentano sequenze di azioni effettuate dal sistema per produrre
risultati di valore per un attore, descrivono i comportamenti desiderati
o Rappresenta i requisiti funzionali
o Evoluzione:
▪ Dal modello dei casi d’uso si passa al modello di analisi, e da lì a quello di progetto
▪ Classificatori (dotati di strutture e operazioni, descritti da statechart) e realizzazioni dei
casi d’uso
• Modello di analisi:
o Descrizione dettagliata dei requisiti
o Raffinamento dei casi d’uso con collaborazioni tra classificatori concettuali
o Permette di creare l’architettura
o Ha carattere temporaneo (vale per le prime iterazioni), viene mantenuto solo per grandi sistemi
o Costruzione (eventualmente usando schede CRC):
▪ Ogni use case è integrato tramite analisi nomi-verbi
▪ Le responsabilità egli use case sono date alle classi (le classi hanno responsabilità in
diversi casi d’uso e devono soddisfare ogni ruolo di collaborazione definito)
▪ Ogni use case è realizzato grazie alla collaborazione tra più elementi
• Modello di design:
o Modello gerarchico: esistono relazioni che attraversano la gerarchia
o Si possono tracciare le realizzazioni degli use case nelle realizzazioni del modello di analisi
o Le realizzazioni degli use case diventano stereotipi di collaborazioni
o Riferimento per l’implementazione
o Costruzione:
▪ Classi e realizzazioni use case progettate per sfruttare prodotti e tecnologie utilizzabili
▪ Raggruppamento classi di progetto in sottosistemi e definizione interfacce tra
sottosistemi
• Modello di deployment:
o Definizione dell’organizzazione fisica del Sistema come rete di nodi computazionali
o Verifica dell’implementabilità degli use case tramite componenti eseguiti sui nodi definiti
• Modello di implementazione:
o Costruzione:
▪ Pianificare le integrazioni del sistema per ogni iterazione
▪ Distribuire sistema e componenti eseguibili sui nodi del modello di deployment
▪ Implementare le classi e i sottosistemi di progetto, passando dalle classi al codice
▪ Fare test unitari sui componenti
o Le classi progettate sono implementate come insiemi di file component
o Le classi vengono compilate e collegate per produrre eseguibili
o Si procede in base alle priorità stabilite dagli use case
 • Modello di test:
o Costruzione:
▪ Verifica che il Sistema implementi le funzionalità descritte negli use case e soddisfi I
requisiti di sistema
▪ Il modello di test è formato dai casi di test (ingressi, condizioni di esecuzione, risultati)
tracciabili ai casi d’uso
▪ Black box: test definiti dai casi d’uso
▪ White box: test definiti dalle realizzazioni

Processo centrato sull’architettura

• L’architettura comporta decisioni su organizzazione del sistema, elementi strutturali, interfacce,
comportamento nelle collaborazioni, composizione di elementi in sottosistemi, stile architetturale
• È centrata sul come e non sul cosa: progetto architetturale e progetto funzionale
• Principi:
o Modularità funzionale: blocchi di classi in base alle funzioni
o Separare il progetto delle interfacce dai sottosistemi di servizio
o Proiezione dei sottosistemi sui componenti di implementazione
o Basso accoppiamento tra sottosistemi: segnali
• Influenze sull’architettura:
o Casi d’uso significativi
o Vincoli e facilitatori (software, standard e politiche, requisiti non funzionali, distribuzione)
o Esperienza (architetture precedenti, pattern)
• Lo sviluppo dell’architettura è iterativo e avviene in fase di elaborazione:
o Decisione sul disegno ad alto livello
o Parti generali per il dominio, scelta dei nodi, selezione di vincoli e abilitatori
o Aspetti specifici dell’applicazione
o Funzionalità completa solo quando l’architettura sarà stabile
• Viste architetturali:
o Per modello di progetto: sottosistemi principali, interfacce, classi principali, classi attive, cicli di
vita
o Per modello di deployment: struttura fisica in termini di nodi connessi, assegnazione di
componenti eseguibili ai nodi
o Per modello di implementazione distinzione responsabilità

Approccio guidato dai rischi

• I rischi determinano iterazioni e priorità
• Le iterazioni esplorano i rischi in ogni fase
• Rischi nella valutazione nuove tecnologie:
o Distribuzione dei processi sui nodi e sincronizzazione
o I casi d’uso possono dipendere da tecniche computazionali non ben sviluppate
• Rischi nella soddisfazione dei requisiti:
o Inadeguatezza dell’estrazione dei requisiti
o Valutazione dell’importanza delle funzioni
• Rischi nella robustezza dell’architettura:
o Casi d’uso selezionati non definiscono adeguatamente la struttura dei sottosistemi
o I framework per il riuso non sono adeguati
o Le nuove versioni del software sono di qualità insufficiente
Documento di visione del sistema
• Realizzato dal manager di prodotto, guiderà l’intero progetto
• Definisce obiettivi, funzionalità e vincoli del nuovo prodotto dal punto di vista degli stakeholders
• Espone una visione chiara del problema, il suo ambito e le soluzioni proposte
• Costituisce la base per il contratto e per la definizione dei requisiti dettagliati, rispetto ai quali è più
breve e generico
• Viene realizzato all’inizio della fase di Inception del processo RUP, si prevede che possa essere
modificato man mano che i requisiti evolvono
• Serve come base per gli use case
• È aggiornato e mantenuto come artefatto separato lungo il progetto
• Comprende:
o Introduzione
o Specifica delle features/requisiti
o Ambito e limitazioni
o Pianificazione
o Definizione del team di progetto
o Descrizione degli stakeholders
o Posizionamento nel mercato
• È strutturato in:
o Introduzione:
▪ Panoramica del documento, ne definisce scopo, ambito (a quali progetti è associato e
tutto ciò che influenza), definizioni, acronimi e abbreviazioni usati, referenze
o Posizionamento:
▪ Opportunità di business del progetto
▪ Problema (descrizione, ambito, impatto, soluzione)
▪ Posizione (la posizione che il profotto intende riempire nel mercato, con target e relative
necessità, categoria, benefici, vantaggi sulla concorrenza)
o Descrizione di stakeholder e utenti:
▪ Demografia del mercato (segmento di mercato interessato, con relativa dimensione,
spesa degli utenti per soddisfare i bisogni che il prodotto risolverà, trend e tecnologie
esistenti, reputazione dell’azienda in quel mercato)
▪ Stakeholders (tipi, individui o organizzazioni che rappresentano, ruolo che giocano –
possono essere utenti, dipartimenti di strategia o legali o di conformità, sviluppatori,
squadre operative)
▪ Utenti (tipi, relazioni col sistema, quali stakeholders li rappresentano – possono essere
esperti o principianti)
▪ Ambienti di lavoro degli utenti (luoghi, tempistiche, altri prodotti usati…)
▪ Profili di stakeholders e utenti (chi rappresentano, descrizione, tipo, responsabilità,
criteri di successo, coinvolgimento, richieste)
▪ Bisogni di stakeholders o utenti (per ogni problema: motivazioni, soluzioni attuali e
soluzioni proposte, importanza relativa, dal punto di vista degli stakeholders)
▪ Alternative o competitors (alternative ritenute disponibili dagli stakeholders, punti di
forza e debolezza dei competitors)
o Panoramica del prodotto:
▪ Prospettive (inserire il prodotto nel contesto di prodotti correlati e ambiente
dell’utente, precisare se il prodotto è indipendente o parte di un sistema più ampio, e in
tal caso mostrarne le relazioni)
▪ Capacità (riassumere i benefici del prodotto e le funzionalità che li forniranno)
▪ Assunzioni e dipendenze (elencare le assunzioni che se cambiate altererebbero il
documento e i fattori che influenzano le funzionalità del prodotto)
▪ Costi e prezzi (impatti e vincoli dovuti a costi e prezzi)
▪ Licenze e installazione (problemi di licenze e installazione possono influenzare lo
sviluppo)
o Funzionalità del prodotto:
▪ Capacità ad alto livello del sistema richieste per fornire benefici agli utenti, che
tipicamente necessitano di un input per produrre un risultato
▪ Mantenere la descrizione a un livello di dettaglio abbastanza generale da essere capito
da tutti, ma sufficiente a dare informazioni utili a chi deve realizzare il diagramma degli
use case, che approfondirà queste funzionalità
▪ Descrivere cosa e perché, non come
▪ Ogni funzionalità dev’essere utile per utenti, operatori o sistemi esterni
▪ Descrivere anche problemi di usabilità da risolvere
▪ Queste funzionalità saranno la base di definizione del prodotto, gestione del campo
d’interesse e del progetto
o Vincoli:
▪ Annotare vincoli di progettazione, vincoli esterni, requisiti operativi o normativi, altre
dipendenze
o Fasce di qualità:
▪ Definire le fasce di qualità per performance, robustezza, tolleranza agli errori, usabilità,
e altre caratteristiche non descritte dalle funzionalità
o Precedenza e priorità:
▪ Definire la priorità delle funzionalità del sistema
o Altri requisiti del prodotto:
▪ Standard applicabili (elencare tutti gli standard a cui il prodotto deve aderire, e.g. legali,
di comunicazione, di piattaforma, di qualità e sicurezza)
▪ Requisiti di sistema (sistemi operativi, piattaforme di rete, configurazioni, memoria,
periferiche e software di accompagnamento supportati)
▪ Requisiti di performance (e.g. larghezza di banda, throughput, accuratezza, affidabilità,
tempi di risposta…)
▪ Requisiti ambientali (e.g. temperatura, umidità, radiazioni, condizioni di utilizzo,
ambiente del’lutente, disponibilità di risorse, gestione e soluzione di errori, problemi di
manutenzione)
o Requisiti di documentazione:
▪ Note di rilascio, file leggimi (novità, compatibilità con versioni precedenti, avvisi di
installazione e aggiornamento, problemi risolti e conosciuti)
▪ Aiuto online (sistema di supporto agli utenti online, a volte considerato un sotto-
progetto)
 ▪
Guide d’installazione (istruzioni di installazione, configurazione e aggiornamento)
▪
Etichettatura e imballaggio (tipi di testi ed immagini da inserire nel software,
imballaggio)
o Appendice – attributi delle funzionalità:
▪ Stato: definisce il progresso lungo la vita del progetto (e.g. proposto, approvato,
inserito)
▪ Beneficio: beneficio derivante dalla funzionalità, in base a cui si possono classificare i
requisiti, attribuendogli diverse priorità (e.g. critico, importante, utile)
▪ Sforzo: il team di sviluppo stima lo sforzo richiesto per implementare la funzionalità, in
termini di codice, funzioni, tempo
▪ Rischio: il team di sviluppo stima i livelli di rischio, in base alla probabilità che il progetto
attraversi eventi indesiderabili; può essere alto, medio o basso; può essere ricavato
indirettamente dall’incertezza della stima della pianificazione
▪ Stabilità: basata sulla probabilità che la funzionalità cambi, usata per stabilire priorità e
determinare gli elementi da chiarire
▪ Target release: prima versione del prodotto che includerà la funzionalità
▪ Assegnato a: team a cui è affidato il lavoro sulla funzionalità
▪ Motivazione: sorgente/spiegazione della funzionalità richiesta

Da: Wikipedia, IBM

Esempio: https://www.utdallas.edu/~chung/RE/Presentations10F/Team-hope/1%20-%20VisionDoc.pdf
Studio di fattibilità
• Studio preliminare sulle implicazioni che il sistema avrà una volta costruito e sulla sua convenienza
• Per avere senso dovrebbe essere economico e veloce, per essere poi eventualmente approfondito in
seguito
• Contiene:
o Definizione preliminare del problema
o Possibili scenari che illustrino diverse strategie di soluzione
o Costi temi e modalità di sviluppo delle strategie
• Risponde a domande come:
o Il sistema contribuisce al raggiungimento degli obiettivi del destinatario a cui è rivolto? Qual è il
suo impatto?
o Quali sono i problemi con i processi attuali e come il sistema potrà risolverli?
o Può il sistema essere implementato con le tecnologie correnti (quali?) e con costi e tempi
"prevedibili" e accettabili?
o Quali abilità richiede la realizzazione del sistema?
o Può il sistema essere integrato con sistemi pre-esistenti?
o Le informazioni possono essere trasferite verso o da altre organizzazioni?
o Quali attività il sistema dovrà supportare e cosa potrà essere lasciato fuori?
• Considerati tali fattori, si conclude con una raccomandazione sul continuare o meno lo sviluppo del
sistema, in base a:
o Alternative possibili
o Risorse di denaro, tempo e abilità necessarie per l’attuazione del progetto
Analisi del contesto
• Si usa un diagramma del contesto del sistema per rappresentare i confini tra il sistema e il suo ambiente,
mostrando le entità che interagiscono col sistema stesso
• Il diagramma è una vista ad alto livello del sistema
• Vengono rappresentati input e output del sistema
• Non viene rappresentata la struttura interna del sistema
• Al centro vi è il sistema, circondato da ambienti, attività e altri sistemi che ci interagiscono
• Lo scopo è mettere l’attenzione su fattori esterni determinanti per lo sviluppo di requisiti e vincoli del
sistema
• Viene realizzato all’inizio per concordare sul campo su cui si sta lavorando, e dev’essere scritto in
linguaggio naturale per essere compreso anche dagli stakeholders
• Si usa un diagramma a building blocks, le cui componenti sono:
o Entità/attori: scatole etichettate, una al centro per il sistema e le altre intorno per gli attori
esterni
o Relazioni: linee etichettate tra il sistema e gli altri attori
• Gli alberi decisionali e la memorizzazione dei dati sono rappresentati negli schemi di flusso del sistema
• Gli attori esterni possono anche essere divisi in categorie:
o Attivi: attori dinamici che mirano al raggiungimento di obiettivi
o Passivi: attori statici che interagiscono raramente col sistema
o Cooperativi: attori utilizzati dal sistema per ottenere i risultati desiderati
o Autonomi/indipendenti: attori che influenzano indirettamente il sistema, ad esempio
imponendo vincoli

Da: https://en.wikipedia.org/wiki/System_context_diagram
Use-cases
• Rappresentano una situazione in cui il sistema è usato per soddisfare uno o più requisiti dell’utente
• Catturano una parte di funzionalità che il sistema fornisce
• Descrivono i requisiti di sistema dall’esterno
• Specificano solo ciò che il sistema dovrebbe fare: i requisiti funzionali
• Vi si possono assegnare priorità e rischi
o Per derivarne il carico di lavoro necessario per il sistema
o Per stabilire quali scartare o rimandare se sorgono problemi
• Rappresentano un valore tangibile per l’utente, quindi possono essere usati per tracciare il progresso
del progetto
• Aiutano a costruire situazioni e procedure per i test del sistema
• Si possono distinguere requisiti “shall” e “should”:
o I primi devono essere soddisfatti
o I secondi non sono critici ma desiderabili, se ci sono ritardi vengono sacrificati per primi
• Possono essere semplici o complessi
• Dalla prospettiva dell’utente rappresentano un uso completo del sistema, che comprende interazioni col
sistema ed output dal sistema

Attori
• Entità esterne al sistema che interagiscono col sistema
• Sono rappresentati con uno stick-man o una “stereotyped box”, con un’etichetta col nome (che deve
essere chiaro per i clienti e per i
designer del sistema)
• Possono essere persone o sistemi di
terze parti
• Sono scatole nere: non interessa
come funzionano e non possono
essere modificati
• Tra attori possono esistere particolari
relazioni, come quella di
generalizzazione: A generalizza B se
può fare tutto ciò che può fare B e
qualcosa in più
• Tricky actors:
o Il clock di sistema interagisce
col sistema invocandone
alcuni comportamenti, non è
influenzato dal design del
sistema, aiuta a mostrare che
il sistema svolge operazioni
in base al momento corrente
 o Oltre agli utenti, come attori possono essere presenti figure professionali che si occupano di
installazione, revisione, manutenzione, aggiornamento… che possono avere diritti di veto, o
possono dover applicare requisiti non funzionali importanti, e se questi attori vengono
tralasciati tali aspetti del sistema non saranno documentati

Definire e disegnare gli use-cases

• Specificare le interazioni degli attori col sistema
• Trasformare i requisiti in un chiaro insieme di compiti che il sistema deve svolgere
• Rappresentare le interazioni come ovali
• Verificare che gli use-cases siano qualcosa che fornisce un risultato misurabile all’utente o a un sistema
esterno
• Usare linee di comunicazione per mostrare che un attore partecipa a uno use-case, unendo lo stick-man
dell’attore all’ovale dello use-case
• Ad uno use-case possono partecipare più attori
• È preferibile non dotare le linee di comunicazione di frecce per rappresentare flusso di informazioni o
chi inizia lo use-case (queste informazioni sono contenute nella descrizione dettagliata dello use-case)
• È possibile rappresentare il confine del sistema tracciando un rettangolo (scatola) che contenga gli use
case e lasci all’esterno gli attori, dandogli il nome del sistema
• I dettagli degli use-cases possono essere definiti nelle descrizioni degli use-cases:
o Descrizione testuale che accompagna ogni use-case
o Non ci sono regole pratiche e rigide per scriverla
o Comprende, in riferimento allo use-case che accompagna:
▪ Dettaglio della descrizione: cosa significa e a cosa serve
▪ Requisiti collegati: quale/i requisito/i soddisfa in parte o completamente
▪ Obiettivo nel contesto: posizione nel sistema e perché è importante
▪ Precondizioni: cosa deve accadere prima che possa essere eseguito
▪ Condizioni finali di successo: condizione del sistema se ha successo
▪ Condizioni finali di fallimento: condizione del sistema se fallisce
▪ Attori primari: gli attori principali che vi partecipano, compresi quelli che lo innescano e
ne ricevono informazioni
▪ Attori secondari: altri attori
▪ Trigger: evento scatenato da un attore che fa partire lo use case
▪ Flusso principale: i passi importanti in un’esecuzione normale
▪ Estensioni: passi alternativi al flusso principale
• Verificare che le descrizioni degli use-cases combacino col diagramma
• Aggiungendo dettagli emergono errori e mancanze che possono essere aggiunti in iterazioni successive

Relazioni tra use-cases

• Servono a dividere il sistema in porzioni gestibili
• Fornire una guida architetturale ai designer del sistema
• Include:
o Se ci sono comportamenti ripetuti tra più use-cases (e quindi ridondanza nelle loro descrizioni),
si possono raccogliere in un nuovo use-case
o I primi due useranno il terzo tramite relazione <<include>>
 o Lo use-case alla testa della freccia tratteggiata usa tutti i passi dello use-case incluso
o Nella descrizione degli use-cases che includono quello nuovo bisogna togliere la parte
ridondante e usare il campo Included Cases e la sintassi include::<nome dello use-case> per
indicare dove viene usato lo use-case incluso
o Vantaggi:
▪ Non c’è bisogno di aggiornare i passaggi in più punti quando è necessaria una modifica
▪ Fornisce un’indicazione sul design: lo use-case incluso dovrà essere una parte di sistema
riusabile
• Generalizzazione:
o Se ci sono comportamenti ripetuti tra più use-cases ma con alcune differenze, si può creare uno
use-case generale (o padre), da cui gli altri (specializzati) ereditano le caratteristiche comuni
o Si rappresenta con una freccia dallo use-case che rappresenta il caso particolare a quello che
rappresenta il caso generale
o Nella descrizione bisogna specificare solo i passi aggiuntivi necessari per il caso particolare
o Con una generalizzazione, il caso particolare eredita tutti i passi e le relazioni di quello generale
• Extend:
o A differenza dell’uso che si fa del termine estendere in linguaggi come Java, non ha a che fare
con l’ereditarietà
o Se ci sono comportamenti ripetuti tra più use-cases ma in maniera opzionale, dipendente da
scelte effettuate a tempo di esecuzione o implementazione, si può creare uno use-case che
estenda gli altri, per non ripetere una sequenza di azioni nel flusso alternativo di più use-cases
o Lo use-case esteso usa completamente quello che lo estende, quando si verifica una condizione
Use Case Overview Diagrams
• Fornisce un’immagine ampia del contesto o dominio del sistema
• Nonostante il nome, in genere non contengono gli use-cases
• L’interno del sistema in genere è nascosto
• Utile per mostrare informazioni per capire com’è posizionato il sistema nel mondo, tra cui le relazioni tra
attori
• Non contengono dettagli, ma sono un punto di partenza per i dettagli del resto del modello
Modellare il flusso di lavoro del sistema – Diagramma di attività
• Mentre gli use-case mostrano cosa il sistema dovrebbe fare, i diagrammi di attività specificano come il
sistema dovrebbe raggiungere quei risultati
• I diagrammi di attività mostrano azioni ad alto livello concatenate per rappresentare un processo che si
svolge nel sistema
• Sono utili per modellare processi di business: insiemi di task collegati che raggiungono un risultato di
business
• Sono gli unici diagrammi che forniscono una visione del sistema dal punto di vista dei processi
• Essendo semplici, sono adatti a descrivere processi a un’audience ampia
• Sono utili a mostrare un flusso di eventi relativo a uno use case meglio nella descrizione dello use case
stesso
• Componenti del diagramma:
o L’attività è lanciata dal nodo iniziale (un cerchio pieno)
o La fine dell’attività è rappresentata dal nodo finale (due cerchi concentrici, con quello interno
pieno)
o Le azioni (rettangoli con gli angoli arrotondati) sono i passi importanti che avvengono nel
processo/nell’attività, come comportamenti o computazioni o task
o Il flusso dell’attività è mostrato con frecce dette archi o cammini, in modo da indicare la
direzione deflusso da un’azione alla successiva
o Il primo nodo a forma di diamante è una decisione, da lì partono due archi etichettati con
condizione booleane, solo uno dei quali sarà seguito, a seconda dell’esito della decisione
o Il secondo è un merge, che combina gli archi partenti dalla decisione, segnando la fine del
comportamento condizionale
o L’intera attività (composta di più azioni) può essere racchiusa in un rettangolo arrotondato detto
activity frame, utile per mostrare più attività nello stesso diagramma, scrivendo il nome
dell’attività in alto a sinistra
• Decisioni e merge:
o Le decisioni sono usate quando si vogliono eseguire azioni diverse a seconda di una condizione
o Sono rappresentate con un nodo a diamante con un arco entrante e più archi uscenti
o Ogni argo che si dirama contiene una condizione di guardia booleana scritta in parentesi quadre,
per determinare quale arco sarà seguito
o I flussi diramati si riuniscono in un merge, che segna la fine del comportamento condizionale
iniziato alla decisione, ed ha più archi entranti e uno uscente
o Il diagramma è più chiaro se le condizioni di guardia sono:
▪ Mutualmente esclusive: altrimenti, se ci sono due condizioni vere non è chiaro quale
ramo vada seguito
▪ Complete: altrimenti, ci sono condizioni in cui il flusso non può proseguire (si può usare
una condizione “else” per evitare questa situazione)
o Se ci sono più archi entranti in un’azione, si aspetta il completamento di tutti i relativi flussi
prima di procedere, per questo in caso di flussi alternativi si fanno convergere tutti in un merge
prima di procedere
• Flussi paralleli:
o Azioni parallele o concorrenti si rappresentano usando fork e join, disegnati con barre spesse
 o Dopo un fork il flusso si divide in più flussi eseguiti insieme (un arco entrante e più archi uscenti)
o Il join significa che tutte le azioni entranti devono finire prima che il flusso possa procedere,
anche se non finiscono tutte insieme (più archi entranti e un arco uscente)
• Eventi dipendenti dal tempo:
o Il tempo può essere utile per modellare periodi di attesa, processi che partono con un intervallo
di tempo regolare…
o I time events sono rappresentati con una clessidra
o Un arco entrante nella clessidra indica che il time event è attivato una volta, ed ha la durata
indicata
o Una clessidra senza archi entranti indica un time event ricorrente, attivato con la frequenza
indicata
o Se un’attività è lanciata periodicamente il flusso può partire col time event anziché con il nodo
iniziale
• Invocare altre attività:
o Se un diagramma diventa troppo grande, o se la stessa sequenza di azioni occorre spesso, si
possono raccogliere alcune attività in un diagramma che verrà invocato da un altro di livello più
alto
o La chiamata a un’attività è indicata con un forcone capovolto accanto al nome dell’azione, e
prende il nome di call activity node, che chiama l’attività col nome dell’azione
o È utile mettere l’activity frame attorno alle attività invocate da altre per metterne in evidenza il
nome
• Iniziare un’attività:
o Con un nodo iniziale
o Ricevendo dati in input (vedi)
o In risposta a un time event (vedi)
o In risposta a un segnale (vedi)
• Terminare attività e flussi:
o Si possono disegnare attività con più nodi finali, ma sono più comprensibili se ne hanno uno solo
o Interrompere un’attività:
▪ A volte un processo, anzi che concludersi normalmente, può essere terminato da un
evento (e.g. interrotto da un utente), ciò si rappresenta con regioni di interruzione
▪ Una regioni di interruzione consiste in un rettangolo tratteggiato che circonda le azioni
che possono essere interrotte e l’evento che causa l’interruzione, seguito da una freccia
a forma di fulmine
 o Concludere un flusso:
▪ È possibile usare un nodo finale di flusso per indicare che un flusso muore senza
terminare l’intera attività
▪ È rappresentato da un cerchio con una X all’interno

Oggetti
• A volte degli oggetti sono importanti per il processo che si sta modellando
• Nel diagramma di attività si possono usare nodi oggetto per mostrare i dati che scorrono attraverso
un’attività, raffigurandoli come rettangoli
• Un nodo oggetto rappresenta un oggetto disponibile in un particolare punto nell’attività, si può usare
per mostrare che l’oggetto è usato, creato o modificato dalle azioni circostanti
• Si possono usare input pin o output pin per indicare un oggetto che va in input a un’azione o che è
l’output di un’azione, rispettivamente, disegnando un quadratino a sinistra dell’azione nel primo caso e
a destra nel secondo, al posto dell’oggetto, con sopra l’etichetta dell’oggetto
• Si può mostrare come viene ottenuto un oggetto specificando la trasformazione in una nota
• Si può mostrare il cambiamento di stato di un oggetto che passa attraverso un’attività scrivendo lo stato
tra parentesi quadre nel rettangolo del nodo oggetto
• I nodi oggetto possono essere input e output anche per intere attività (oltre che per singole azioni), in tal
caso sono disegnati a cavallo del confine dell’activity frame, e prendono il posto dei nodi iniziale e finale

Segnali
• Le attività possono coinvolgere persone, sistemi o processi esterni
• Nei diagrammi delle attività, i segnali rappresentano le interazioni con i partecipanti esterni
• I segnali sono messaggi che possono essere inviati o ricevuti
• Un segnale ricevuto sveglia un’azione, il ricevente sa come reagire e aspetta che arrivi un segnale ma
non sa esattamente quando
• Un segnale inviato è rivolto a un partecipante esterno, non modellato nel diagramma, che
probabilmente fa qualcosa in risposta al segnale
• Giunto ad un nodo invia segnale il sistema non aspetta una risposta per passare all’azione successiva: i
segnali sono inviati in maniera asincrona
• Giunto ad un nodo ricevi segnale il sistema aspetta che il segnale sia ricevuto per procedere
• Spesso si combinano nodi invia segnale e nodi ricevi segnale, perché bisogna aspettare la risposta a un
segnale che si è inviato, in tal caso l’effetto è quello di una chiamata sincrona, che aspetta una risposta
per procedere
• Un nodo ricevi segnale senza flusso entrante significa che l’attività resta in attesa di ricevere un segnale,
ed è lanciata solo quando questo avviene
Partizioni
• A volte un’attività può coinvolgere diversi partecipanti, le partizioni mostrano quale partecipante è
responsabile di quale azione
• Una partizione divide il diagramma in righe (o colonne), dette swimlanes (“corsie di nuoto”), che
contengono le azioni compiute da un partecipante
• La responsabilità di un’azione può essere mostrata anche usando annotazioni, scrivendo il nome del
partecipante tra parentesi nel nodo

Connettori
• I connettori servono a semplificare diagrammi con molte azioni, collegando due punti con un simbolo
anziché con una linea
• Si rappresentano con un cerchio contenente il suo nome, tipicamente di un solo carattere
• Si usano a coppie: uno con un arco entrante e una con un arco uscente, il secondo riprende da dove il
primo ha interrotto

Regioni di espansione
• Le regioni di espansione mostrano che le azioni in una regione sono eseguite per ogni elemento in una
collezione di input
• Si rappresentano con un grande rettangolo tratteggiato con gli angoli arrotondati e quattro quadratini
allineati su due lati, a rappresentare le collezioni di input e output
Analisi nomi-verbi
• Si analizza tutta la documentazione disponibile selezionando nomi e verbi:
o Nomi: potenziali classi o attributi
o Predicati nominali: potenziali classi o attributi
o Verbi: potenziali responsabilità di classe
• Un’altra possibile classificazione:
o Nomi propri: istanze
o Nomi comuni: classi/tipi/ruoli
o Doing verbs: metodi (verbi “dinamici”, che indicano azioni)
o Being verbs: strutture di classificazione (tipo essere, sembrare, stare)
(che roba sono?!)
o Having verbs: strutture di composizione (verbi che indicano possesso)
(vedi Composite structure diagram)
o Verbi di stato: condizioni di invarianza (tipo piacere, preferire, capire, dubitare, sapere)
o Verbi modali: semantica dei dati, precondizioni, postcondizioni, o condizioni di invarianza
(tipo volere, dovere, potere)
o Verbi transitivi: metodi
o Verbi intransitivi: eccezioni o eventi dipendenti dal tempo
o Aggettivi: valore di attributo o classe
o Frase aggettivale: associazione, operazione
(definizioni da qui e qui)
• Non esiste un’unica soluzione formalmente corretta, bisogna affidarsi all’intuizione e all’esperienza
• L’analisi mette al centro l’utente, di cui bisogna capire le intenzioni, esprimibili come postcondizioni
• Comprendere l’Ontologia permette di introdurre oggetti essenziali piuttosto che accidentali (importanti
piuttosto che arbitrari)
• Gli oggetti sono strutture concettuali rappresentanti astrazioni universali
• I giudizi importanti per l’analisi object-oriented sono:
o Qualità, che individua attributi, esprime proprietà accidentali difficilmente riutilizzabili
o Riflessione, che individua relazioni
o Categoria, che individua generalizzazioni, esprime astrazioni ad alto livello, essenziali
o Valore, che individua regole
• Gli attributi sono funzioni che prendono oggetti come valori, possono avere valori astratti/essenziali o
accidentali
• Un concetto dovrebbe essere astratto come classe se:
o Si possono dire diverse cose interessanti su di esso
o Ha proprietà non condivise da altre classi
o Ci sono affermazioni che distinguono questa classe da altre classi più ampie a cui essa
appartiene
o I confini del concetto sono imprecisi
o Il numero di delle classi complementari la cui unione è la naturale generalizzazione di questa è
basso
 • Regola per distinguere oggetti essenziali: ciò che si può dire sull’oggetto è più che ciò che si può ottenere
elencando i suoi attributi e metodi, cosa è essenziale dipende dal contesto (e.g. non c’è molto da dire
sulla classe degli ‘impiegati che non sanno volare’ a meno che non ci si occupi di liee aeree)
• Oggetti con troppi metodi o attributi devono far pensare di essersi allontanati dalle necessità degli
utenti
• Bisogna considerare il riuso nella raccolta dei requisiti
• Analisi e progettazione sono arti creative: bisogna prendere percezione e intenzione degli utenti e
trasformarle, collaborando con loro

Da: http://uml-tutorials.trireme.com/uml_tutorial_4.htm
Schede CRC
• Metodo di brainstorming iterativo che coinvolge sviluppatori, esperti e committenti
• Servono a definire le classi principali e le loro interazioni all’inizio del progetto, e in seguito per
controllare lo sviluppo
• Class-Responsibility-Collaborator:
o Classe: collezione di oggetti simili (per gli oggetti più importanti)
o Responsabilità: compiti principali (ciò che una classe conosce o fa)
o Collaborazioni: altri oggetti che cooperano per soddisfare una responsabilità
• Descrizione:
o Un oggetto è una persona, un posto, una cosa, un evento o un concetto rilevanti per il sistema
o Possono includere anche superclassi e sottoclassi
o Per le classi usare nomi singolari semplici
o Una classe può cambiare il valore di ciò che sa, ma non di ciò che altre classi sanno
o Se una classe deve assolvere una responsabilità ma non ha abbastanza informazioni, si rivolge
alla classe che le ha, che diviene sua collaboratrice
o Una collaborazione può essere una richiesta di informazioni o una richiesta di fare qualcosa
• Utilizzo:
o Le schede vengono scritte su post-it e posizionate su un piano, dove la loro vicinanza fisica
rispecchia quella logica
o Qualcuno legge lo scenario di uno use case e gli altri mettono insieme gli oggetti che collaborano
alla sua realizzazione
o Quando un oggetto ne usa un altro, il secondo è detto collaboratore del primo
o Per eseguire degli “stress test” sulle schede, si può alterare lo scenario per vedere se il design
regge
o Si possono realizzare molte schede, eliminando quelle non utilizzate solo alla fine del processo:
nel frattempo si possono proporre più alternative, mettendo quelle momentaneamente scartate
su un lato
o Può essere utile scrivere decisioni chiave sull’allocazione delle responsabilità e disegnare
diagrammi per le interazioni più importanti
• Creare un modello CRC:
o Si può realizzare un modello CRC per ogni requisito o use-case
o Trovare le classi: identificare i blocchi di costruzione per l'applicazione, in genere le classi
principali sono 3-5
o Trovare le responsabilità: cosa fa una classe e quali informazioni bisogna mantenere che la
riguardano
o Definire i collaboratori: chiedersi per ogni responsabilità della classe se essa è in grado di
assolverla da sola (questo può portare ad aggiungere responsabilità ad altre classi o nuove
classi)
o Muovere in giro le carte: disporre vicine le schede di classi che collaborano, questo aiuta a capire
le relazioni tra le classi
o Procedendo con lo sviluppo del progetto si tornerà ad apportare modifiche ai modelli CRC
Da: http://alistair.cockburn.us/Using+CRC+cards, http://agilemodeling.com/artifacts/crcModel.htm
Classi di analisi – Entity -Control-Boundary Pattern
• L’Entity-Control-Boundary Pattern è una generalizzazione del Model-View-Controller pattern, usasto per
sistemi anziché per interfacce utente
• Si usano tre stereotipi:
o <<entity>>:
▪ Mantengono informazioni persistenti
▪ Tengono un comportamento organizzato attorno a un insieme di dati coeso
▪ Derivabili da classi di modelli di business o di dominio, ma più orientate al sistema
▪ Concetto strettamente legato a database o altri sistemi di gestione di dati
o <<boundary>>:
▪ Interazioni tra sistemi e attori
▪ Oggetti che si interfacciano con gli attori
▪ Rappresentano elementi del sistema che gestiscono le comunicazioni con gli elementi al
di fuori dell’area che si sta progettando (e.g. interfaccia utente o API)
▪ Prendono un segnale da utenti, altri sistemi o hardware e li consegna ad oggetti interni
▪ Inviano messaggi ad utenti, altri sistemi o hardware
▪ Raccolgono dati dagli attori e/o mostrano dati agli attori
o <<control>>:
▪ Mediano tra boundary ed entity
▪ Contengono la logica necessaria a gestire gli oggetti e le loro interazioni (algoritmi per
gestione e manipolazione dei dati)
▪ Potranno essere implementati come classi ma anche come semplici metodi
▪ Eseguono i flussi degli use case → sono associabili ai casi d’uso
▪ Boundary ed entity potrebbero realizzare uno use case senza bisogno di control
• Regole di comunicazione:
o Gli attori comunicano solo con le interfacce
o I boundary comunicano solo con control e attori
o Le entity comunicano solo con i control
o I control comunicano solo con boundary ed entity o con altri control
• Architettura esagonale:
o Gli attori interagiscono con i boundary
o I boundary inviano comandi ai control
o I control possono mandare richieste ai
boundary per ricevere più informazioni
dagli attori
o I control poi aggiornano le entity
o I boundary aggiornano se stessi quando
bisogna riflettere cambiamenti delle
entità
• Distinguere domini di problema e soluzione
• Minimizzare accoppiamento
• Introdurre ereditarietà solo se le gerarchie
esistono nel dominio
• Package:
o Raggruppa elementi in relazione
semantica
o Definisce confini semantici nel modello
o Fornisce unità per sviluppo parallelo (design)
o Fornisce namespace incapsulato con unicità di nomi
o Ogni elemento appartiene a uno e un solo package
o Contengono casi d'uso, classi di analisi, realizzazioni di casi d'uso
o Identificazione package d'analisi:
▪ Raggruppare cluster di classi coesi
▪ Trovare gerarchie di ereditarietà
▪ Casi d'uso per processo o attore possono indicare package
▪ Alta coesione dentro package
▪ Basso accoppiamento fra package
▪ Evitare package annidati
o In caso di dipendenze cicliche:
▪ Fondere in unico package
▪ Fattorizzare elementi comuni in nuovo package
▪ Fare attenzione all’orientamento delle associazioni
• Il modello di analisi definisce la struttura, anche architetturale
• Viene descritto in:
o Diagrammi di classi di analisi (classi di analisi che interagiscono per realizzare un caso d’uso)
o Diagrammi di interazione (collaborazioni e interazioni tra istanze che lo realizzano, istantanee
dell’esecuzione)
o Raffinamento di requisiti e casi d’uso
• Link:
o https://stackoverflow.com/questions/683825/in-uml-class-diagrams-what-are-boundary-
classes-control-classes-and-entity-cl
o http://www.ivencia.com/softwarearchitect/chapter1/chapter1_6.htm (utile anche dopo)
o ArchWebcast03_DaiCasiDUsoAlModello.pdf (utile anche dopo)
o http://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm
o http://epf.eclipse.org/wikis/openuppt/openup_basic/guidances/concepts/entity_control_boun
dary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html
o https://youtu.be/sv6z9f_hU0E
o https://youtu.be/JU12_1DuTjI
o https://youtu.be/dgwUYMKoxnA
o https://youtu.be/oAvO6g9SRks
Diagramma delle classi (di progetto)
• Le classi sono il cuore di ogni sistema object-oriented
• Le classi descrivono i diversi tipi di oggetti che compongono la struttura di un sistema, e che soddisfano
le necessità espresse dagli use case
• I diagrammi delle classi mostrano le classi e le loro relazioni
• Cos’è una classe:
o È un tipo di qualcosa
o È come il progetto di come sarà costruito un oggetto, con le sue caratteristiche
o Ogni oggetto costruito da una classe è un’istanza della classe
o Comprende le informazioni di stato (attributi) e comportamento (operazioni) di un oggetto
o Scartare dettagli irrilevanti per un contesto si dice astrazione, ed è importante per avere un
buon punto di partenza quando si progettano le classi del sistema
o Il principio dell’incapsulamento dell’approccio object oriented allo sviluppo di sistemi prevede
un oggetto contenga i dati e le operazioni che lavorano su quei dati
o L’incapsulamento permette a una classe di nascondere dettagli di come funziona, così è
possibile modificare i dettagli interni senza che cambi nulla all’esterno
• Le classi in UML:
o In UML una classe è rappresentata da un rettangolo diviso in tre sezioni contenenti il nome
(obbligatoria), gli attributi e le operazioni della classe
o Il nome di una classe determina il tipo dell’oggetto che sarà istanziato in base ad essa
o Il diagramma delle interazioni mostra come gli oggetti lavorano insieme quando il sistema è in
funzione

Visibilità
• Usare le caratteristiche di visibilità permette di applicare l’incapsulamento, controllando l’accesso ad
attributi, operazioni, o intere classi
• Il simbolo della visibilità è posto prima del nome dell’attributo/operazione a cui si riferisce

• Public:
o Accessibile direttamente da ogni altra classe
o L’interfaccia di una classe pubblica consiste in attributi e operazioni pubblici, accessibili e
utilizzabili dalle altre classi
o Poiché le altre classi possono dipendere dall’interfaccia pubblica di una classe, questa deve
cambiare il meno possibile
o In genere è meglio evitare attributi pubblici, ma non sempre (e.g. se si tratta di costanti)
• Protected:
o Accessibile dai metodi della classe e delle sottoclassi
o Serve a permettere alle sottoclassi di accedere a un attributo o un’operazione della superclasse
senza aprirlo/a all’intero sistema
 o [In Java anche le classi nel package possono accedere a campi protected]
• Package:
o Accessibile solo dalle classi nello stesso package
• Private:
o Accessibile solo dalla classe che lo contiene
o Utile se si intende cambiare un attributo o un’operazione senza modificare le classi che vi
accedono
o Gli attributi dovrebbero essere principalmente private o protected, molto raramente public

Attributi – lo stato della classe

• Gli attributi di una classe sono i pezzi di informazione che rappresentano lo stato di un oggetto
• Possono essere rappresentati o inserendoli nel rettangolo di una classe (inline), o tramite associazione
con un’altra classe (associated)
• In genere si preferisce rappresentare attributi come inline se sono di classi standard (e.g. String), in
modo da occupare meno spazio, e come associated altrimenti, in modo da evidenziare le relazioni con
altre classi
• In ogni caso un attributo ha una signature contenente proprietà di visibilità, nome e tipo

• Due attributi nella stessa classe non possono avere lo stesso nome
• Il tipo può essere o una classe o un tipo primitivo
• I nomi devono essere descrittivi e rispettare le convenzioni del linguaggio usato
• Se ad un attributo è applicata la proprietà readOnly, il suo valore non può essere cambiato dopo che il
suo valore iniziale è stato impostato [equivale a final in Java]
• Altre proprietà che un attributo può avere sono union, subsets, redefines e composite
• Molteplicità:
o Un attributo può rappresentare uno o più oggetti di un certo tipo
o [*] indica che un attributo può essere presente in qualsiasi quantità
o [a..b] indica che un attributo può essere presente da a a b volte
o In un attributo associated, il valore dal lato dell’attributo indica quanti di quegli attributi
saranno mantenuti nella classe, il valore dal lato della classe indica con quanti oggetti del tipo
della classe sarà associato l’attributo
o La proprietà unique impone che non ci possano essere due elementi uguali nell’insieme
associato a un attributo (è il default per gli attributi con molteplicità)
o La proprietà not unique indica che sono permessi i duplicati
 o La proprietà ordered indica che gli elementi nell’insieme associato a un attributo sono
mantenuti con un certo ordine (il default è l’inverso)

Operazioni – il comportamento della classe

• Le operazioni di una classe descrivono cosa fa una classe ma non necessariamente come
• Un’operazione rappresenta un contratto che dichiara quali comportamenti terrà una classe
• L’insieme delle operazioni di una classe dovrebbe coprire tutti i comportamenti della classe, includo il
lavoro che mantiene gli attributi della classe ed eventualmente dei comportamenti aggiuntivi
strettamente associati con la classe
• In UML si rappresentano con una signature che comprende proprietà di visibilità, nome, parametri, tipo
di ritorno

• I parametri sono usati per specificare l’informazione fornita a un’operazione per permetterle di
completare il suo compito, comprendono nome e tipo
• Il tipo di ritorno è specificato dopo i due punti e indica il tipo dell’oggetto che sarà restituito
dall’operazione, non è necessario per i costruttori

Componenti statici di una classe

• In UML classi, operazioni e attributi possono essere dichiarati statici
• Attributi ed operazioni non statici sono associati alle istanze della classe: ogni oggetto della classe ha la
propria copia
• Attributi e operazioni statici sono associati alla classe stessa: sono condivisi da tutti gli oggetti di una
classe ed hanno una durata che va oltre quella delle istanze della classe
• I membri statici sono utili per implementare il Singleton Design Pattern, che consiste nell’assicurarsi che
di una classe sia costruito solo un oggetto, tipicamente tenendo una referenza statica all’istanza nela
classe, accedendovi tramite un’operazione statica

Relazioni tra classi

• Le relazioni tra classi possono essere più o meno forti, in base al modo in cui le classi coinvolte
dipendono l’una dall’altra
• Se due classi sono fortemente dipendenti l’una dall’altra si dice che hanno un alto accoppiamento, e le
modifiche all’una influenzeranno l’altra
• In genere l’alto accoppiamento è negativo, quindi più le relazioni sono forti più occorre fare attenzione
• Dipendenza:
o Una dipendenza tra due classi dichiara che una classe ha bisogno di sapere cose riguardanti
un’altra classe per usarne gli oggetti (e.g. leggere il contenuto dell’oggetto o usare funzioni della
classe)
o La dipendenza tra due classi assicura che lavorano insieme a runtime
o Spesso si usa per classi che forniscono funzioni di utilità generiche
• Associazione:
o Un’associazione tra due classi dichiara che una classe conterrà una referenza a uno o più oggetti
dell’altra classe, come attributi
o Se una classe lavora con un oggetto di un’altra, probabilmente le è associata
o Si può indicare la navigabilità di un’associazione per indicare quale classe contiene l’attributo
che supporta la relazione, usando una freccia per la navigabilità e una croce per la non
navigabilità
o A volte un’associazione introduce una nuova classe, per mostrare che la classe introdotta è in
relazione con le due classi in relazione in virtù della relazione stessa; la nuova classe è collegata
all’associazione con cui è associata con una linea tratteggiata
• Aggregazione:
o È una versione più forte dell’associazione
o Indica che una classe possiede ma può condividere oggetti di un’altra classe
o Si rappresenta con una linea con un diamante vuoto dalla parte del possessore
o L’implementazione è la stessa che per le associazioni: l’introduzione di un attributo
• Composizione:
o È una versione ancora più forte dell’associazione
o Indica che una classe possiede oggetti di un’altra classe (e generalmente non li condivide), se il
possessore è eliminato avviene lo stesso per gli oggetti posseduti
o Si rappresenta con una linea con un diamante pieno dalla parte del possessore
o Rappresenta le parti interne che compongono una classe
o L’implementazione è la stessa che per le associazioni: l’introduzione di un attributo
• Generalizzazione (o ereditarietà):
o Descrive una classe che è un tipo di un’altra classe (mentre associazione, aggregazione e
composizione descrivono classi che sono parti di un’altra classe)
o La classe più generale è detta genitore, base o superclasse
 o Le classi specializzate sono dette figli o classe derivate
o Si rappresenta con una linea con una freccia vuota dalla parte del padre
o Le generalizzazioni hanno senso solo in una direzione
o Riutilizzo di codice:
▪ Una classe eredita e riusa tutti gli attributi e i metodi della sua superclasse con visibilità
public, protected o default, quindi la generalizzazione permette di riutilizzare attributi e
comportamenti tra le due classi
▪ Una classe ha un forte accoppiamento con l’implementazione della sua superclasse,
quindi la generalizzazione va usata solo quando effettivamente la prima è una versione
specializzata della seconda e non ogni volta che è comodo riutilizzare codice, invece si
può usare la delegazione
o Ereditarietà multipla:
▪ In UML una classe può ereditare da più superclassi
▪ Spesso si evita di usarla perché introduce complicazioni: è un problema se due
superclassi hanno attributi od operazioni che si sovrappongono
▪ È supportata da C++ ma non da C# e Java

Vincoli
• A volte si vogliono limitare i modi in cui una classe può operare, per esprimere questi vincoli si usa
l’Object Constraint Language
• Esistono tre tipi di vincoli applicabili ai membri delle classi:
o Invarianti:
▪ Vincoli che devono essere sempre veri, altrimenti il sistema si trova in uno stato non
valido
▪ Sono definiti sugli attributi delle classi
o Precondizioni:
▪ Vincoli definiti su un metodo e controllati prima che questo sia eseguito
▪ Sono usate per validare parametri di input di un metodo
o Postcondizioni:
▪ Vincoli definiti su un metodo e controllati dopo che questo è stato eseguito
▪ Sono usate per descrivere come i valori sono modificati da un metodo
• I vincoli possono essere indicati o tra parentesi graffe accanto al campo a cui si riferiscono o in una nota
a parte

Classi astratte
• A volte creando classi generiche si preferisce lasciare l’implementazione di alcune operazioni alle
sottoclassi che le specializzano, questa scelta si può indicare usando metodi astratti, scritti in corsivo
• Se una parte di una classe è dichiarata astratta, la classe stessa deve essere dichiarata astratta
scrivendone il nome in corsivo
• Una classe astratta non può essere istanziata
• Se una sottoclasse implementa tutti i metodi astratti della superclasse, divenendo concreta, può essere
istanziata
• Le classi astratte sono utili per definire comportamenti e attributi comuni
 • Classi astratte e interfacce sono molto usate nel definire generici ruoli e comportamenti che formano i
design pattern

Interfacce
• Se si vogliono dichiarare metodi astratti per una classe che ha una sola relazione di ereditarietà, si può
usare un’interfaccia, al posto della classe
• Un’interfaccia è un insieme di operazioni senza implementazioni, come una classe astratta con solo
metodi astratti
• Le interfacce sono più sicure da usare delle classi astratte poiché evitano i problemi legati all’ereditarietà
multipla
• A volte le interfacce contengono attributi, generalmente statici e spesso costanti
• Non si può istanziare un’interfaccia
• Sono rappresentate con una notazione di classe stereotipata o con la loro notazione a cerchio:

• La classe che realizza (implementa) un’interfaccia si indica con una freccia tratteggiata verso l’interfaccia
nel primo caso e con un’associazione all’interfaccia nel secondo
• Se una classe realizza un’interfaccia ma non implementa tutti i suoi metodi, va dichiarata astratta
• Le interfacce sono perfette per separare il comportamento che una classe deve tenere da come questo è
realizzato
• Gli oggetti di una classe che implementa un’interfaccia possono essere chiamati col nome
dell’interfaccia, quindi altre classi possono dipendere dall’interfaccia piuttosto che dalle classi, il che è
positivo perché riduce l’accoppiamento delle classi

Templates (o classi parametriche o generiche)

• Sono utili per posticipare la decisione su quale classe collaborerà con una classe
• Si indicano con un rettangolo tratteggiato contenente un placeholder del tipo del parametro (e.g. E)
• Per usare un template, bisogna legarlo ai suoi parametri (binding):
o Cioè stabilire con quale classe lavorerà, ovvero quale classe sostituirà il placeholder
o Creando una sottoclasse specificando il binding:
o Oppure effettuando il binding a runtime, specificando il tipo del parametro alla creazione
dell’oggetto
o Nel secondo caso il binding riguarda l’oggetto e non la classe, per cui serve un diagramma degli
oggetti, che usa le classi per mostrare come sono usate mentre il sistema è in esecuzione
Diagramma dei packages
• Quando un progetto è composto da molte classi conviene dargli una struttura organizzandole in gruppi
logicamente correlati (e.g. classi per la GUI insieme)
• I gruppi di classi in UML sono modellati con i packages, simili ai packages di Java e ai namespaces di C#
• Oltre che ad organizzare gli elementi, i packages aiutano a controllare gli accessi alle classi, a dividere il
lavoro tra i programmatori, a stabilire come dividere il software in moduli di deployment
• I packages sono rappresentati con una cartella con una linguetta
• Il contenuto dei packages può essere rappresentato o direttamente nel package o all’esterno e collegato
con una linea, il nome del package si scrive nel primo caso nella cartella e nel secondo nella linguetta
• Un package può contenere anche altri packages annidati, per semplificare la notazione anziché
disegnare tutta la gerarchia bastano il più interno e il più esterno, i nomi di quelli intermedi andranno
nell’etichetta del secondo: packageA::packageB::packageC, dove packageA è il più esterno
• I packages evitano collisioni tra nomi di classi diverse, creando dei namespaces:
o Quindi se un elemento di un package vuole usare un elemento di un altro package deve
specificare dove si trova l’elemento desiderato, fornendo il “fully-scoped name”:
packageName::className
o Gli elementi in un namespace devono avere nomi unici
o Elementi in un package annidato possono accedere a elementi nel package che lo contiene
senza specificare il fully-scoped name
• Gli elementi in un package possono avere visibilità:
o Pubblica: indicata con un più davanti al nome, l’elemento è accessibile fuori dal package
o Privata: indicata con un meno davanti al nome, l’elemento è accessibile sono da altri elementi
nel package
• Dipendenze tra packages:
o Se una classe in un package A ha bisogno di usare una classe in un package B, A dipende da B, e
si indica con una freccia tratteggiata
o Capire le dipendenze tra i packages è fondamentale per la stabilità del software: se un package
viene modificato può danneggiare packages che ne dipendono
o Dipendenze complicate possono rendere un sistema fragile, quindi bisogna:
▪ Evitare dipendenze cicliche, o creando un nuovo package con gli elementi comuni, o
unendo i packages coinvolti
▪ Dipendere nell’ordine di stabilità, ossia un package dovrebbe dipendere solo da
packages più stabili di lui (quindi un package stabile dipende da pochi packages, un
pachage instabile dipende da molti packages)
• Import e access tra packages:
o Quando un package ne importa un altro, gli elementi nel primo possono usare quelli nel
secondo senza usare il fully-scoped name
o Il package importato è chiamato target package
o La relazione di import è indicata con una freccia tratteggiata con lo stereotipo <<import>>
o Un package può anche importare solo uno specifico elemento in un altro package, anziché il
package intero
o Quando un package ne importa un altro può accedere solo agli elementi pubblici
 o Visibilità dell’import:
▪ Se è pubblico (default) gli elementi importati hanno visibilità pubblica nel namespace in
cui sono importati
▪ Se è privato gli elementi importati hanno visibilità privata nel namespace in cui sono
importati, e si usa lo stereotipo <<access>>
▪ La differenza emerge quando si crea una catena di import/access: nel primo caso gli
elementi vengono passati attraverso tutta la catena, nel secondo no
• Si possono usare i package anche per raggruppare gli use case, questo:
o Aiuta ad organizzare il modello
o Permette di vedere quali attori interagiscono con quali porzioni del sistema
Diagramma di sequenza
• Si pongono tra diagrammi degli use case (che mostrano cosa deve fare il sistema) e diagrammi delle
classi (che mostrano come è composto il sistema) per spiegare come i componenti del sistema si
comportano e interagiscono per ottenere i risultati desiderati
• Fanno parte dei diagrammi di interazione, insieme a diagrammi di comunicazione e di tempo
• Mostrano quali interazioni scattano all’esecuzione di uno use case e in che ordine si susseguono
• Partecipanti in un diagramma di sequenza:
o Un diagramma di sequenza è composto da un insieme di partecipanti: le parti del sistema che
interagiscono tra loro durante la sequenza
o I partecipanti sono disposti in modo da non sovrapporsi, tipicamente indicati con nome:
ClasseCorrispondente
o Ognuno ha una sua lifeline che indica che il partecipante esiste in quel punto della sequenza, è
effettivamente utile quando un partecipante è creato o distrutto durante la sequenza
o È più corretto pensare ai partecipanti come componenti del sistema che come oggetti software
• Tempo:
o Il tempo in un diagramma di sequenza parte dalla cima della pagina, sotto al nome del
partecipante più in alto, e scorre verso il basso
o L’ordine in cui sono posizionate le interazioni indica l’ordine in cui avvengono nel tempo
o Non viene rappresentata la durata delle interazioni
• Per approfondire: https://www.ibm.com/developerworks/rational/library/3101.html

Eventi, segnali e messaggi

• La più piccola parte di un’interazione è un evento
• Un evento è ogni punto di un’interazione in cui accade qualcosa
• Gli eventi sono i blocchi che formano i segnali/messaggi
• Un’interazione avviene quando un partecipante invia un messaggio ad un altro
• Sono raffigurati con:
o Una freccia che va dal message caller al message receiver
o Una freccia di ritorno opzionale nel verso opposto
o Le activation bar di message caller e receiver (opzionali):
▪ Quando un messaggio è inviato a un partecipante questo scatena o invoca un’azione di
chi lo riceve, a questo punto il ricevente è detto attivo
▪ Per mostrare che un partecipante è attivo, ovvero sta facendo qualcosa, si può usare
una activation bar
▪ Dal lato del mittente indica che questo è impegnato mentre invia il messaggio e dal lato
del destinatario indica che questo è occupato dopo aver ricevuto il messaggio
o La signature del messaggio:
▪ Nella forma attributo = nomeDelMessaggio (argomenti): tipoDiRitorno
▪ Si possono specificare più argomenti separandoli con una virgola, nella forma nome:
classe
• Messaggi annidati: quando un messaggio scatena l’invio di altri messaggi da parte del suo destinatario,
questi nuovi messaggi sono detti annidati nel primo
 • Frecce dei messaggi:
o Diversi tipi di frecce indicano diversi tipi di messaggi:

o Messaggio sincrono:
▪ Invocato quando il chiamante aspetta che il ricevente ritorni dall’invocazione del
messaggio
▪ In Java corrisponde all’invocazione di un metodo
o Messaggio asincrono:
▪ Necessario quando si vogliono lanciare più interazioni nello stesso momento, anche
senza aspettare che ritornino
▪ Il chiamante non aspetta che l’invocazione del messaggio ritorni prima di procedere
▪ In java viene implementato usando i thread
o Messaggio di ritorno:
▪ Si può usare (opzionalmente) alla fine di una activation bar per mostrare che il flusso di
controllo dell’attivazione ritorna al chiamante
▪ A livello implementativo corrisponde a raggiungere la fine di un metodo chiamando
esplicitamente il return
▪ Un partecipante può anche inviare un messaggio a se stesso, per dividere una grande
activation in pezzi più piccoli e gestibili
o Messaggi di creazione e distruzione:
▪ I partecipanti non vivono necessariamente per l’intera durata dell’interazione del
diagramma di sequenza, ma possono essere creati e distrutti col passaggio di messaggi
▪ Per mostrare che un partecipante è creato si può o passare un messaggio create(…) o
usare la notazione dropped participant box
▪ La cancellazione di un partecipante è mostrata dalla fine della sua lifeline con la croce di
cancellazione
▪ In Java la creazione corrisponde all’utilizzo di new, mentre non c’è un corrispettivo per
la distruzione esplicita, che viene effettuata dal garbage collector, in tal caso si può o
lasciare l’oggetto vivo ma inutilizzato o utilizzare una croce di distruzione senza metodo
associato

Frammenti di sequenza
• Serve a modellare cicli e flussi alternativi
• È rappresentato da una scatola che racchiude una porzione delle interazioni di un diagramma di
sequenza
• Alcuni tipi di frammento hanno bisogno di un parametro contenente una condizione di guardia
• Nell’angolo in alto a sinistra della scatola del frammento c’è un operatore che indica il tipo del
frammento:
o Operatore opt, frammento opzionale:
▪ Tutte le interazioni che contiene saranno eseguite in base al risultato della condizione di
guardia
▪ Utile in corrispondenza di una relazione <<extend>> in uno use case, ossia quando si
riusa un insieme di interazioni solo in certe condizioni
o Operatore ref, frammento di referenza:
▪ Rappresenta un riferimento a una porzione del diagramma che viene disegnato a parte
per non creare confusione
▪ Non ha bisogno di parametri
▪ È utile per riutilizzare un insieme di interazioni comuni
o Operatore assert, frammento di asserzione:
▪ Specifica che le interazioni che contiene devono avvenire esattamente come sono
indicate, altrimenti il frammento è dichiarato non valido e viene sollevata un’eccezone
▪ Utile per specificare che ogni passo di un’interazione deve avere successo (ad esempio
in una transazione)
o Operatore loop, frammento di ciclo:
▪ Prende come parametri il minimo e il massimo di iterazioni e una condizione di guardia
▪ Ripete le istruzioni che contiene un numero specificato di volte finché la condizione di
guardia risulta falsa
o Operatore break, frammento di interruzione o eccezione:
▪ Se la condizione di guardia è vera vengono eseguite le interazioni di questo frammento
anziché quelle restanti del frammento che lo racchiude (tipicamente un ciclo), da cui
quindi si esce
o Operatore alt:
▪ Prende come parametri una o più condizioni di guardia, compresa [else]
▪ Vengono eseguire interazioni che contiene in base a quale condizione di guardia risulta
vera per prima
o Operatore neg, frammento negativo (non valido):
▪ Dichiara che le interazioni in questo frammento non saranno eseguite
▪ Utile per “commentare” un insieme di interazioni prima di eliminarle definitivamente,
soprattutto se si ha un tool che esegue effettivamente il codice derivato dai diagrammi
▪ Può servire anche a indicare qualcosa che non va fatto
o Operatore par, frammento parallelo:
▪ Specifica che le interazioni che contiene possono essere eseguite in parallelo
▪ Indica che non serve rendere le operazioni thread-safe tramite locking
o Operatore region, frammento di regione critica:
▪ Indica che le interazioni che contiene sono parte di una regione critica
▪ Tipicamente una regione critica è un’area in cui partecipanti condivisi vengono
aggiornati
 ▪ Indica che occorre usare dei lock per evitare interleaving di interazioni parallele
o Altro: http://www.uml-diagrams.org/sequence-diagrams-combined-fragment.html
 Esempio
Rappresentazione del procedimento per creare un nuovo account blog regolare:
1. come diagramma di use case;
2. come diagramma di attività;
3. come diagramma di sequenza base;
4. come diagramma di sequenza intermedio;
5. come diagramma di sequenza con frammenti – visione generale;
6. come diagramma di sequenza con frammenti – porzione per la selezione del tipo di account.

1.

2.
 3.

4.
5.

6.
Piano dei test
• Il piano dei test descrive tutti gli sforzi necessari per lo svolgimento dei test nelle varie fasi del progetto:
la strategia, la pianificazione, i criteri di inizio e fine, i rischi e le relative soluzioni
• Dovrebbe essere cominciato quanto prima e sviluppato iterativamente, aggiungendo sezioni quando
l’informazione è disponibile
• Mettere in chiaro da subito requisiti, strategie e risorse necessarie velocizza revisione, feedback e
approvazione dei test
• Tipi di piano dei test:
o Master test plan: contiene informazioni ad alto livello, meno soggetto a cambiamenti
o Detailed test plan: contiene informazioni specifiche, è aggiornato col progredire del progetto
o Iteration test plan: contiene solo le informazioni su una certa iterazione
o Acceptance test plan: descrive le attività associate ai test di accettazione
Cosa chiedersi per redigere il piano
• Cosa devo testare? Descrizione: sistemi, applicazioni, hardware
• Quali funzioni testerò? Lista delle funzioni e descrizione del sistema e delle sue componenti separate
• Come le testerò? Strategia: tipi di test e loro applicazione agli oggetti da testare
• Quando le testerò? Sequenza di lavoro: preparazione ed effettuazione dei test, analisi dei risultati nel
contesto delle fasi di sviluppo pianificate
• Criteri di avvio dei test: piattaforma di test pronta, funzionalità richieste sviluppate, documentazione
disponibile
• Criteri di completamento dei test: i risultati dei test combaciano coi criteri di qualità del prodotto
• Quali sono l’ambiente del sistema, i requisiti per i test, i rischi e le loro soluzioni?
Linee guida
• Identificare i requisiti per il test:
o Indicano lo specifico target di un test
o Devono essere comportamenti osservabili e misurabili
o Non c’è un rapporto 1-1 tra use case + requisiti non funzionali e requisiti per i test
o I requisiti possono venire da use case, specifiche supplementari, requisiti di design, documento
di architettura…
o Requisiti per i test funzionali:
▪ Almeno uno da ogni use case
▪ Meglio uno da ogni flusso di ogni use case
o Requisiti per i test di performance:
▪ Si misura l’efficienza del target del test misurando il tempo di risposta e/o l’uso di
risorse, in diverse condizioni
▪ Vanno rintracciati nelle specifiche supplementari, in particolare dove si parla di tempo,
dove si confronta il comportamento di più elementi, o dell’applicazione sotto più
configurazioni, affidabilità operativa lungo un periodo di tempo, configurazioni o vincoli
▪ Bisogna ottenere almeno un requisito per ognuno degli elementi così individuati
o Requisiti per i test di affidabilità:
▪ Vanno rintracciati nelle specifiche supplementari, o nelle linee guida per interfaccia
utente, design e programmazione, in particolare dove si parla di affidabilità o resistenza
al fallimento, integrità e struttura del codice, utilizzo di risorse
 ▪ Bisogna ottenere almeno un requisito per ognuno degli elementi così individuati
• Valutare i rischi associati ai requisiti:
o Permette di assegnare una priorità ai test: gli use case che comportano maggiori rischi o che
hanno più probabilità di fallire dovrebbero essere testati per primi
o Identificare gli indicatori della gravità di rischio che saranno usati:
▪ H: rischio alto, non tollerabile; esposizione esterna dei server; la compagnia ha gravi
perdite finanziarie o di reputazione e responsabilità
▪ M: rischio medio, tollerabile ma non desiderabile; esposizione esterna minima; la
compagnia può soffrire finanziariamente, ma ha scarsa responsabilità e perdita di
reputazione
▪ L: rischio basso, tollerabile; esposizione esterna scarsa o assente; la compagnia ha
perdite finanziarie o responsabilità scarse o assenti; la reputazione della compagnia non
è toccata
o Scegliere la prospettiva in base alla quale assegnare gli indicatori di gravità di rischio:
▪ Effetto: l’impatto o la conseguenza del fallimento di un requisito; per determinarlo
rispondere alla domanda “cosa succederebbe se …?”
▪ Causa: un esito indesiderabile causato dal fallimento di un requisito; per determinarlo
rispondere alla domanda “come potrebbe succedere che …?”
▪ Probabilità: la probabilità che un requisito fallisca; determinata in base a tasso di
fallimento, tasso di cambiamento, complessità, origine
o In base alla prospettiva scelta, assegnare a ogni requisito da testare un indicatore di gravità di
rischio e giustificare la scelta
• Determinare il profilo operazionale dei requisiti:
o Identificare e descrivere gli indicatori dell’importanza del profilo operazionale:
▪ H: usato molto frequentemente o da molti attori o use case
▪ M: usato frequentemente o da diversi attori o use case
▪ L: usato infrequentemente o da pochi attori o use case
o Valutare:
▪ Il numero di volte che un attore/uno use case esegue il requisito in un periodo di tempo
▪ Il numero di attori/use case che eseguono il requisito
o In base a queste valutazioni, associare un indicatore ad ogni requisito e fornire una motivazione
• Stabilire le priorità dei test:
o Serve ad assicurare che:
▪ Lo sforzo dei test sia concentrato sui requisiti più appropriati
▪ I requisiti più critici, significativi o rischiosi siano affrontati al più presto
▪ Tutte le dipendenze siano considerate nel test
o Identificare e descrivere gli indicatori di priorità dei test:
▪ H: deve essere testato
▪ M: dovrebbe essere testato, ma solo dopo H
▪ L: potrebbe essere testato, ma solo dopo H ed M
o Considerare:
▪ Indicatore della gravità di rischio
▪ Indicatore dell’importanza del profilo operazionale
▪ Descrizione dell’attore
 ▪ Obbligazioni contrattuali
o Strategie per assegnare una priorità a un test:
▪ Usare l’indicatore più alto
▪ Indicare il fattore più importante e usare il suo indicatore
▪ Combinare gli indicatori di più fattori
▪ Calcolare una media pesata degli indicatori dei vari fattori
o In base a queste considerazioni e strategie, associare un indicatore ad ogni requisito e fornire
una motivazione
• Definire la strategia dei test:
o Descrive l’approccio generale e gli obiettivi di un test
o Deve contenere:
▪ Tipo del test e obiettivi: stabilire chiaramente il tipo del test e gli obiettivi del test
(specificando perché si sta svolgendo il test), così da ridurre la confusione e minimizzare
i fraintendimenti
▪ Stadio del test: stabilisce la fase in cui il test sarà eseguito (tipicamente i test funzionali
si svolgono in tutte le fasi, quelli di performance dei componenti in fase di test di unità e
di integrazione, quelli di performance di carico di lavoro e stress in fase di test di sistema
e di accettazione, quelli di affidabilità in fase di test di unità e di integrazione ed
eventualmente di sistema)
▪ Tecnica: descrive come i test saranno implementati ed eseguiti, le azioni da compiere
durante l’esecuzione dei test e i metodi usati per valutare i risultati
• Criteri di completamento:
o Servono ad identificare:
▪ La qualità del prodotto accettabile
▪ Quando i test sono stati completati con successo
o Devono includere:
▪ Funzioni, comportamenti o condizioni da misurare
▪ Metodi di misurazione
▪ Criteri o grado di conformità alla misura
• Considerazioni particolari: identificare influenze o dipendenze che potrebbero avere un impatto sullo
svolgimento dei test, tra cui:
o Risorse umane, come la necessità di personale esterno al gruppo dei test
o Vincoli, come la necessità di attrezzature
o Requisiti particolari, come schedulazione dei test o accesso al sistema
Checklist
• Il piano dei test identifica l’ambito dei test stabilendo:
o Stadi e tipi di test da implementare ed eseguire
o Caratteristiche e funzioni da testare e da non testare
o Assunzioni rischi e contingenze che possono avere effetti sui test
• Il piano dei test identifica gli artefatti usati per generare i contenuti del piano stesso
• Ogni requisito (come descritto in uno use case) ha associato un test o la motivazione per cui non è
necessario testarlo
• Ad ogni requisito è assegnata una priorità di test e un tipo di test
 • Per ogni tipo di test è descritta una strategia, che comprende:
o Il nome del test e i suoi obiettivi
o Una descrizione di come il test sarà implementato ed eseguito
o Una descrizione dei criteri e dei metodi di misurazione usati per valutare la qualità del target del
test e per stabilire il completamento del test
• Tutte le risorse necessarie ad implementazione e svolgimento dei test sono state identificate (hardware,
software e personale)
• Il piano dei test comprende una lista di milestone che identificano le attività del progetto e i relativi test
• Il piano dei test identifica gli artefatti creati dalle attività di test, quando sono disponibili, come saranno
distribuiti, il loro contenuto e come vanno usati
Tipi di test
• Di componenti:
o Responsabilità dello sviluppatore
o Possono riguardare singole funzioni, classi (testare funzioni e attributi) o interfacce (cercare
errori di interfaccia o assunzioni non valide)
• Di sistema:
o Responsabilità di un gruppo di testing indipendente
o Basati sulle specifiche del sistema
o Di integrazione:
▪ Il gruppo di testing ha accesso al codice ed esegue i test mentre si integrano i
componenti
▪ Si cercano i problemi sorti dall’integrazione dei componenti
▪ Dall’alto in basso (aggiungendo elementi allo scheletro) o dal basso all’alto (integrazione
di componenti infrastrutturali con aggiunta di quelli funzionali)
▪ Approcci: convalida architetturale, dimostrazione di sistema, implementazione test,
osservazione test
o Di rilascio:
▪ Il gruppo di testing verifica il sistema completo, come black-box
▪ Test basato sulle specifiche del sistema e non sulla sua implementazione
• Per validazione:
o Servono a dimostrare che i requisiti sono soddisfatti
o Hanno successo quando mostrano che il sistema è corretto
• Per difetti:
o Servono a scoprire difetti o errori
o Hanno successo quando mostrano un difetto (di algoritmo, computazione, documentazione,
limite, temporizzazione, prestazioni, rispetto a standard)
• Prestazionali: si aumenta il carico di lavoro del sistema finché le prestazioni non sono inaccettabili
• Da sforzo: il sistema è portato oltre i limiti previsto per vedere come reagisce (il fallimento non
dev’essere catastrofico)
• Strutturali (white-box): si parte dalla conoscenza del programma per generare i casi di test, con
l’obiettivo di testare ogni istruzione
• Dei cammini: si cerca di testare ogni possibile cammino nel programma
Per approfondire
• http://sce.uhcl.edu/helm/RationalUnifiedProcess/process/modguide/md_tstpl.htm
• http://sce.uhcl.edu/helm/RationalUnifiedProcess/process/activity/chklists/ck_tstpl.htm
• https://www.utest.com/articles/how-to-create-a-test-plan
• https://www.ibm.com/developerworks/rational/library/04/r-3239/r-3239-pdf.pdf
• http://www.fit.vutbr.cz/study/courses/ITS/public/ieee829.html
Gestione dei rischi e garanzia di qualità
• Identificare i rischi ed elaborare un piano per minimizzarne l’effetto
• Tre aree di influenza:
o Di progetto: influenzano temporizzazione o risorse
o Di prodotto: influenzano qualità o prestazioni software
o Di business: influenzano l’organizzazione
Processo di gestione dei rischi
• Identificazione: elencare i potenziali rischi
o Tecnologici
o Legati a persone
o Organizzativi
o Nei requisiti
o Nelle stime
• Analisi: stabilire probabilità (molto bassa, bassa, moderata, alta, molto alta) ed effetti (catastrofici, seri,
tollerabili o insignificanti), assegnare priorità
• Pianificazione: evitare o minimizzare le conseguenze
o Tecniche:
▪ Avoid: eliminare il rischio o ritirarsi
▪ Reduce: ottimizzare, mitigare
▪ Retain: accettare e contabilizzare
▪ Transfer: esternalizzare o assicurare
o Per ogni rischio stabilire una strategia di gestione:
▪ Per evitare: ridurre la probabilità che il rischio si verifichi
▪ Per minimizzare: ridurre l’impatto del rischio
▪ Piani di contingenza: come trattare il rischio se emerge, scatenati da un trigger
• Osservazione: tenere sotto controllo i rischi durante il progetto, per valutare se ci siano cambiamenti
sulle probabilità o sugli effetti, usando opportuni indicatori
• Risk Mitigation, Monitoring, and Management:
o Ridurre in anticipo probabilità e impatto dei rischi
o Osservare fattori che indicano cambiamenti delle probabilità dei rischi
o Implementare piani di contingenza
• Per ogni rischio individuato bisogna indicare anche il trigger: la causa prima (condizione od evento) che
fa sì che il rischio si verifichi
Principi di Software Quality Assurance
• Approccio alla gestione della qualità
• Metodi e strumenti di software engineering efficaci
• Conduzione di revisioni tecniche, test multi-strato, misure, controlli
• Controllo di documentazione e aggiornamenti
• Procedure di adesione a standard
• La tracciabilità dai requisiti al codice è fondamentale per valutare la qualità
• Qualità del progetto:
o Analisi dei requisiti e delle specifiche
o Progetto architetturale dettagliato
 o Fattori di qualità: produttività, visibilità, tempestività, qualità specifiche

• Qualità del prodotto:

o Segue i requisiti?
o L’implementazione segue il progetto?
o Soddisfa gli obiettivi prestazionali?
o Fattori di qualità: affidabilità, manutenibilità, riparabilità, evolvibilità, robustezza, riusabilità,
prestazioni, portabilità, usabilità, comprensibilità, verificabilità, interoperabilità
• Controllo della qualità tramite ispezioni, revisioni e test (ogni modulo deve avere specifiche definite e
misurabili)
• Assicurazione della qualità:
o Tramite funzioni di auditing e reporting
o Per dare informazioni sulla qualità al management e permettere identificazione e soluzione di
problemi di qualità
• Attività di SQA:
o Svolte da un gruppo indipendente
o Preparare un piano di SQA: valutazioni, audizioni e revisioni da eseguire, standard applicabili al
prodotto, rapporto e tracciamento degli errori, documenti da produrre, quantità/tipo di
feedback per gli sviluppatori
• Costi della qualità:
o Prevenzione: pianificazione, revisioni, test dell’attrezzatura
o Valutazione:
▪ (unità prodotte - unità difettose) / unità prodotte
▪ Progetto singolo vs. evoluzione storica
▪ Calibratura dell’attrezzatura e manutenzione
▪ Test
o Errore:
▪ Fallimento interno (prima del rilascio) → rilavorazione, riparazione, analisi del fallimento
▪ Fallimento esterno (dopo il rilascio) → risoluzione, ritiro e rimpiazzo, supporto, garanzia
▪ I costi per trovare e riparare un difetto crescono da prevenzione a individuazione e da
interno a esterno (se un difetto non viene trovato subito si amplifica)
• Revisioni:
o Permettono di scoprire il 75% degli errori di progetto (che sono il 60% del totale)
o Portano risparmi per sviluppo e manutenzione
o Svolte in riunioni brevi, di 3-5 persone, con focus ristretto, in cui all’introduzione dello
sviluppatore seguono domande e risposte, quindi la decisione se accettare il modulo senza
modifiche o con la revisione o respingerlo
Gestione della configurazione del software (SCM)
• Identificare e controllare il cambiamento, assicurare che l’implementazione sia corretta, riportare il
cambiamento agli altri
• Una buona ingegneria del software gestisce il cambiamento in modo efficiente
• Software configuration item: artefatti da gestire in un processo di software engineering (programmi,
documenti, dati)
• Baseline: versioni finali stabilizzate dei prodotti
 • Un item può avere implementazioni diverse sviluppate e valutate in parallelo
• Per gestire l’evoluzione si usano controllo di versione, di accesso e di sincronizzazione
• Per ogni cambiamento si decide se effettuarlo, e in tal caso viene realizzato e verificato
Gestione dei rischi e della qualità
• Ridurre i rischi incrementa la qualità del processo
• Alcuni aspetti della gestione di qualità sono di fatto azioni di individuazione e mitigazione dei rischi:
o Pianificazione avanzata della qualità del prodotto
o Analisi delle modalità e degli effetti di fallimento
o Gestione della qualità dei fornitori
o Non conformità/Azioni correttive e preventive
o Pratiche di buona produzione
o Procedure operative standard
o Controllo statistico del processo
o Analisi dei rischi e punti di controllo critici
• Alcuni aspetti di sostenibilità sono strettamente legati a fattori di qualità e di prevenzione/mitigazione
dei rischi, ad esempio per quanto riguarda energia, ambiente, salute e sicurezza, rischio operativo,
amministrazione del prodotto, segnalazioni
• Assumendo una prospettiva ampia sul rischio un’azienda può bilanciare i bisogni di qualità e sostenibilità
con le sue altre esigenze
• Il Quality Risk Management è l'insieme delle capacità culturali e tecnologiche, di leadership, di gestione
dei processi aziendali, che le organizzazioni stabiliscono per creare un approccio collaborativo per
identificare, quantificare e mitigare i rischi operativi, di prodotti, fornitori e catena di fornitura che
possono influire sulla qualità
Link utili
• https://www.qualitydigest.com/inside/quality-insider-column/linking-quality-management-and-risk-
management.html#
• https://www.qualitydigest.com/inside/quality-insider-article/risk-assessment-and-quality-management-
system.html
• http://blog.lnsresearch.com/bid/126119/quality-risk-management-a-new-perspective
• http://asq.org/quality-progress/2000/05/career-corner/risk-management-is-it-the-future-of-quality-
management.html
• http://isoconsultantpune.com/iso-90012015-understanding-structure-terminology-concept/risk-based-
thinking/quality-risk-management/
• https://simplicable.com/new/risk-trigger