Sei sulla pagina 1di 32

Progettazione di sistemi informatici (41492) Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.

it

A.A. 2013/2014
ultimo aggiornamento: 22/10/2013 01:25

Sommario
Ciclo di vita ........................................................................................................................................................................ 1 Analisi dei requisiti ........................................................................................................................................................ 2 Specifica dei requisiti .................................................................................................................................................... 2 Importanza dei requisiti ................................................................................................................................................ 2 Effetti cumulativi degli errori ........................................................................................................................................ 3 Definizioni dellanalisi ................................................................................................................................................... 3 Cosa e come modellare................................................................................................................................................. 3 Metodi di analisi............................................................................................................................................................ 3 Il ruolo dellastrazione .................................................................................................................................................. 4 I meccanismi di astrazione ............................................................................................................................................ 4 Linguaggi per la specifica dei requisiti .......................................................................................................................... 4 Progettazione ................................................................................................................................................................ 5 Requisiti per il progettista............................................................................................................................................. 5 Obiettivi della progettazione ........................................................................................................................................ 5 Oggetti............................................................................................................................................................................... 6 Il paradigma a oggetti ................................................................................................................................................... 6 Sviluppo di sistemi ad oggetti ....................................................................................................................................... 7 Benefici dellapproccio a oggetti................................................................................................................................... 8 Object-oriented analysis ............................................................................................................................................... 8 Object-oriented design ................................................................................................................................................. 8 UML ................................................................................................................................................................................... 9 UNIFIED modelling language......................................................................................................................................... 9 UML e gli oggetti ........................................................................................................................................................... 9 Struttura dellUML ........................................................................................................................................................ 9 Costituenti fondamentali ........................................................................................................................................ 10 Meccanismi comuni dellUML ................................................................................................................................. 12 Architettura ................................................................................................................................................................. 13 UP .................................................................................................................................................................................... 14 Come istanziare UP su un progetto ............................................................................................................................ 14 Assiomi dellUP............................................................................................................................................................ 15 Struttura dellUP ......................................................................................................................................................... 16 Flusso di lavoro dei requisiti ........................................................................................................................................... 17

Progettazione di sistemi informatici (41492) Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

A.A. 2013/2014
ultimo aggiornamento: 22/10/2013 01:25

Meta-modello della specifica dei requisiti .................................................................................................................. 17 Flusso di lavoro dei requisiti ....................................................................................................................................... 17 Importanza dei requisiti .......................................................................................................................................... 18 Definire i requisiti........................................................................................................................................................ 18 Organizzare i requisiti ............................................................................................................................................. 18 Individuare i requisiti .............................................................................................................................................. 19 Interviste ................................................................................................................................................................. 20 Questionari.............................................................................................................................................................. 20 Workshop sui requisiti ............................................................................................................................................ 20 Modellazione dei casi duso ............................................................................................................................................ 21 Individuare attori e casi duso ..................................................................................................................................... 21 Subject: il confine di sistema ...................................................................................................................................... 21 Attori ........................................................................................................................................................................... 22 Individuare gli attori ................................................................................................................................................ 22 Casi duso .................................................................................................................................................................... 23 Individuare i casi duso ............................................................................................................................................ 23 Glossario di progetto .................................................................................................................................................. 23 Descrivere i casi duso ................................................................................................................................................. 24 Mappatura dei requisiti .............................................................................................................................................. 25 Casi di applicazione della modellazioni dei casi duso ................................................................................................ 25 Modellazione dei casi duso: tecniche avanzate ............................................................................................................. 26 Generalizzazione tra attori.......................................................................................................................................... 26 Generalizzazione tra casi duso ................................................................................................................................... 27 Include..................................................................................................................................................................... 27 Estende ................................................................................................................................................................... 28 Quando usare le tecniche avanzate ............................................................................................................................ 29 Come scrivere i casi duso ........................................................................................................................................... 29 Mantenere i casi duso brevi e semplici .................................................................................................................. 29 Cosa e come ............................................................................................................................................................ 29 Evitare la scomposizione funzionale ....................................................................................................................... 29 Ingegneria del software .................................................................................................................................................. 30 Esercitazioni .................................................................................................................................................................... 30

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 1 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Ciclo di vita
Definizione strategica Fase decisionale sullarea aziendale oggetto di automazione. Pianificazione Definizione degli obiettivi e dei fabbisogni. Realizzazione di uno studio di fattibilit che si occupa di definire come, in quali tempi e con quali costi realizzabile il sistema richiesto valutando costi e benefici. Controllo di qualit Predisposizione di un piano di controllo della qualit per lintero progetto con lo scopo di garantire il rispetto delle specifiche e la congruenza operativa del sistema. Analisi dei requisiti Modellazione formale della realt descritta dal cliente, produzione di macro specifiche di progettazione. Progettazione del sistema Realizzazione di specifiche indipendenti dagli strumenti che saranno utilizzati per la costruzione del sistema. Progettazione esecutiva Descrizione della struttura e del comportamento dei componenti dellarchitettura. Realizzazione di specifiche per lo sviluppo del sistema. Realizzazione e collaudo in fabbrica Realizzazione del sistema e -test interno sulla base dei casi di prova definiti in fase di analisi. Certificazione Verifica che lo sviluppo del software si congruente ai criteri previsti dal metodo tecnico di progetto e conforme alle specifiche del sistema e alla documentazione di progetto. Installazione Installazione del sistema, configurazione e recupero di eventuali dati pregressi. Collaudo del sistema installato Gli utenti testano il prodotto installato (-test) e rilevano eventuali errori - che possono essere bloccanti (che pregiudicano il collaudo), non bloccanti - problemi di operativit (funzionalit sviluppata non adeguatamente) o funzionali (funzionalit assente). Si conclude con la firma del collaudo. Esercizio Il sistema collaudato messo in produzione (go-live) con progressiva sostituzione del sistema preesistente. Diagnosi e manutenzione Durante lesercizio si possono rilevare errori, che saranno oggetto di manutenzione correttiva, o variazioni del dominio applicativo, che saranno oggetto di manutenzione adattativa. Evoluzione La richiesta o lopportunit di migliorare il sistema o ampliarne le funzionalit, migliorandone loperativit detta manutenzione evolutiva o perfettiva. Messa fuori servizio

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 2 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Analisi dei requisiti


Lanalisi produce un documento di specifica dei requisiti che sar linput per le successive fasi di progettazione e realizzazione. Lanalisi pu rilevare requisiti funzionali (azioni che il software deve rendere possibili e automatizzare) e non funzionali (efficienza, buon uso delle risorse, ). La qualit sar successivamente valutata con la correttezza del software, ovvero la corrispondenza alle specifiche richieste e formalizzate. Loggetto dellanalisi lorganizzazione nel suo complesso: sottosistemi aziendali, risorse, processi, flussi informativi

Specifica dei requisiti


Lutente finale (cliente) e il produttore del software si accordano sulle funzionalit che il sistema dovr rendere disponibili definendo un documento di specifica dei requisiti. La diversit dei linguaggi dellutente e del produttore rappresenta la complessit di questa fase. La qualit della specifica dei requisiti determinata da: Chiarezza: ogni specifica deve indicare il pi chiaramente possibile le operazioni e i soggetti del processo descritto Non ambiguit: il processo deve essere definito in modo completo e dettagliato Consistenza: le specifiche non devono contenere contraddizioni. Requisiti 0.1 - 0.2

Importanza dei requisiti


La definizione chiara, non ambigua, consistente dei processi permette di anticipare eventuali costi di realizzazione e, soprattutto, ridurli. Eventuali errori rilevati, infatti, in fasi via via successiva durante il ciclo di vita del software, generano costi di correzione e gestione sempre maggiori.

Progettazione 0.5
Codifica 1 Test 2 Accettazione 5

Manutenzione 20

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 3 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Effetti cumulativi degli errori


Fase Specifiche dei requisiti Specifiche corrette Esiti Specifiche non corrette

Progettazione

Progetto corretto

Progetto errato

Progetto su specifiche errate

Realizzazione

Software corretto

Errori di programmazione

Software sviluppato da progetto errato

Software sviluppato con specifiche errate

Test

Applicazioni corrette

Errori correggibili

Errori non correggibili

Errori nascosti

Definizioni dellanalisi
Lanalisi lo studio di un problema, prima di intraprendere qualche azione De Marco Lanalisi lo studio del dominio di un problema, che porta ad una specifica del comportamento esternamente osservabile; una descrizione completa, coerente e fattibile di ci che occorre realizzare; una trattazione quantitativa delle caratteristiche operazionali (affidabilit, disponibilit, prestazioni). Coad Lanalisi del problema il momento in cui viene definito lo spazio del prodotto; la descrizione del prodotto comporta la scelta di una soluzione e lesplicitazione del comportamento esterno del prodotto dimostrando che esso soddisfa i requisiti. Davis

Cosa e come modellare


Il processo di analisi incrementale. Porta alla stesura di un insieme di documenti in grado di rappresentare un modello dellorganizzazione e comunicare in modo non ambiguo una descrizione esauriente, coerente e realizzabile dei vari aspetti statici, dinamici e funzionali di un sistema informatico.

Metodi di analisi
Differenti problemi richiedono approcci differenti e differenti strumenti di analisi. Analisi orientata agli oggetti Esempio: un database Identifica gli oggetti e le relazioni tra essi. Le propriet strutturali degli oggetti restano stabili nel tempo. Analisi orientata alle funzioni Esempio: un compilatore Identifica i flussi informativi, la rete dei processi che trasformano i flussi informativi. Definisce gerarchie funzionali. Analisi orientata agli stati Identifica i singoli stati operativi di determinati sistemi e le transizioni tra essi. Esempio: uninterfaccia

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 4 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Il ruolo dellastrazione
Gli oggetti possono essere descritti in termini molto generici e, via via, con maggiori dettagli arrivando a livelli molto specifici. Le funzioni possono essere espresso in modo inizialmente vago e successivamente precisate molto dettagliatamente. Gli stati possono essere descritti a livelli di astrazione alti o specificati in maggiori dettagli.

I meccanismi di astrazione
Classificazione Permette di raggruppare gli oggetti in classi, funzioni o stati in base alle loro propriet. Oggetti Classi

Generalizzazione Classi Superclassi Astrae le caratteristiche comuni fra diverse classi definendo superclassi. Esprime la relazione un (is a). Aggregazione Componente Composto Definisce le relazioni che sussistono tra oggetti, funzioni e stati componenti e composti. Esprime la relazione parte di (part of). Associazione Modella le relazioni che sussistono tra le varie classi.

Linguaggi per la specifica dei requisiti


Linguaggi informali Il linguaggio naturale, utilizzato nella fase di intervista degli utenti, ricco di ambiguit e pertanto non pu essere utilizzato come unico mezzo di definizioni dei requisiti. Linguaggi semiformali Si tratta di notazioni grafiche accoppiate al linguaggio naturale (E/R, DFD). Linguaggi formali Linguaggi di specifica basati sulla logica dei predicati Linguaggi di specifica algebrici Linguaggi concettuali per basi di dati I formalismi operazionali definiscono il sistema descrivendone il comportamento e forniscono una rappresentazione pi semplice (facilit di acquisizione, verifica della correttezza, comprensione); i formalismi dichiarativi definiscono il sistema dichiarando le propriet che esso deve avere evitando le ambiguit.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 5 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Progettazione
la fase che si pone tra la specifica dei requisiti e la codifica, durante la progettazione si decidono le modalit che permetto di passare dal che cosa (definito dallanalisi) al come (realizzazione). Il sistema complessivo diviso in pi sottoinsiemi per poter affrontare complessit inferiori e suddividere il lavoro in gruppi il pi possibile indipendenti.

Due esigenze contrastanti


Astrazione sufficientemente alta, necessaria per un confronto con le specifiche Dettagli tali da fornire informazioni sufficientemente chiare alla codifica

Requisiti per il progettista


La progettazione unattivit altamente creativa, che richiede un insieme di abilit specifiche. Un buon progettista deve: avere una profonda conoscenza di tutto il processo di sviluppo del software essere capace di anticipare i cambiamenti avere inventiva per individuare soluzioni progettuali accettabili anche in mancanza di metodologie sufficientemente espressive maturare un buon grado di esperienza per poter individuare con maggiore rapidit e sicurezza le soluzioni pi opportune.

Obiettivi della progettazione


Produrre software di qualit (coerente alle specifiche funzionali e non funzionali) nel minor tempo e con i minori costi possibili.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 6 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Oggetti
La programmazione Object Oriented offre un modello potente per scrivere programmi: gli oggetti sono black box che mandano e ricevono messaggi; in questo modo si ottengono miglioramenti in termini di mantenimento, riusabilit, modificabilit del codice a fronte di un maggiore sforzo per la progettazione. I programmi OO sono scritti in termini di oggetti del mondo reale, in questo modo sono pi semplici da capire; incoraggiano lincapsulamento (i dettagli di implementazione sono nascosti a chi utilizza gli oggetti) e la modularit (le porzioni di codice non sono dipendenti tra loro e possono essere riutilizzate per realizzare nuovi progetti).

Il paradigma a oggetti
Concetti fondamentali Gli oggetti sono lelemento base del paradigma. Corrispondono ad entit del dominio applicativo . Oggetto
Rappresentano individui che possiedono identit e un insieme di propriet che ne rappresentano lo stato e il comportamento. Ogni oggetto caratterizzato da: unidentit (OID, Object IDentifier) che gli viene associata alla creazione, non modificabile e indipendente dallo stato uno stato definito come insieme dei valori assunti in un certo istante da un insieme di attributi un comportamento definito da un insieme di operazioni; ogni operazione dichiarata dalloggetto specifica un nome, un insieme di oggetti (parametri) e il valore restituito (signature); linsieme di tutte le signature delle operazioni di un oggetto detto interfaccia delloggetto (specifica linsieme di tutte le richieste che possono essere inviate alloggetto). Gli oggetti possono essere rappresentati ad un livello di astrazione superiore caratterizzato da una struttura e da uninterfaccia che definisce le operazioni associate agli oggetti e, quindi, i servizi implementati. Un tipo di dati astratto un sottotipo di un supertipo se la sua interfaccia contiene quella del supertipo. una realizzazione di un tipo di dati astratto, specifica unimplementazione per i metodi a esso associati. Un oggetto sempre istanza di esattamente una classe. Tutti gli oggetti di una classe hanno gli stessi attributi e metodi; esistono due tipi di metodi: quelli che restituiscono astrazioni significative sullo stato delloggetto cui sono applicati e quelli che ne alterano lo stato. Un oggetto incapsula i dati (attributi) e le procedure (operazioni) che modificano i dati. Tramite lincapsulamento un oggetto nasconde lo stato dei dati e limplementazione delle sue operazioni. Il principio di incapsulamento definisce che gli attributi possono essere gestiti (letti e modificati) solo attraverso linterfaccia che loggetto mette a disposizione: i dettagli implementativi sono privati, cio manipolabili direttamente solo dai metodi della classe (e quindi protetti) laccesso agli attributi dallesterno avviene attraverso una ristretta interfaccia pubblica: un sottoinsieme dei metodi della classe un oggetto esegue unoperazione a seguito di una richiesta (messaggio) ricevuta da un altro oggetto. Vantaggi: per utilizzare una classe sufficiente conoscerne linterfaccia pubblica la modifica dellimplementazione di una classe (non della sua interfaccia ) non determina variazioni dellapplicazione meno probabile la generazione di errori in quanto solo i metodi delloggetto possono modificare i dati il debugging velocizzato Un metodo cattura limplementazione di una operazione. I metodi possono essere classificati in: costruttori: costruiscono loggetto con parametri iniziali e restituiscono lOID distruttori: cancellano gli oggetti ed eventuali altri oggetti ad essi collegat accessori: restituiscono informazioni sul contenuto degli oggetti trasformatori: modificano lo stato degli oggetti e di eventuali oggetti ad essi collegati. I metodi possono essere pubblici, privati, protetti.

Astrazione

Classe

Incapsulamento

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it Ereditariet

Pagina 7 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Polimorfismo (late binding)

Delegazione

Il meccanismo di ereditariet permette di basare la definizione e implementazione di una classe su quelle di altre classi. Una sottoclasse eredita dalla sua superclasse struttura e comportamenti; pu per specializzarne limplementazione e aggiungere caratteristiche proprie. Quando una sottoclasse eredit da diverse superclassi si parla di ereditariet multipla (occorre individuare strategie per gestire eventuali conflitti). La derivazione pu essere ulteriormente specializzata costituendo di fatto gerarchie di classi strutturate come alberi o reticoli (nel caso di ereditariet multipla). Lereditariet definisce la relazione un (is a). Il termine polimorfismo (capacit di assumere molteplici forme) utilizzato dal paradigma ad oggetti per descrivere la possibilit di creare metodi con lo stesso nome ma implementazioni differenti. Il meccanismo delloverride permette di definire metodi con lo stesso nome ma signature (insieme dei parametri) differenti. Di fatto il polimorfismo permette di ridefinire, allinterno di una sottoclasse, limplementazione di un metodo ereditato. Abbinato allistanziamento dinamico (bind eseguito in fase di runtime), permette di rispondere ad uno stesso messaggio in modo appropriato a seconda della classe da cui deriva loggetto. Il late binding associato al polimorfismo e allereditariet garantisce est ensibilit e riuso a fronte di un rallentamento dovuto alla gestione di salti condizionati determinati dal bind in fase di runtime (con overhead). Si parla di delegazione quando un oggetto contiene al suo interno un riferimento ad altro oggetto. La delegazione costituisce il meccanismo per implementare associazioni tra le classi. Esistono due forme di delegazione: 1. una forma forte in cui loggetto composto contiene i suoi componenti (aggregazione) 2. una forma debole in cui gli oggetti sono dichiarati singolarmente e loggetto composto referenzia i singoli componenti (composizione)

Sviluppo di sistemi ad oggetti


Lobiettivo principale dellapproccio orientato agli oggetti migliorare la produttivit aumentando lestendibilit, la riusabilit e controllando complessit e costi di manutenzione. La decomposizione funzionale unanalisi di tipo top-down tradizionalmente impiegata nel paradigma procedurale. In essa lapproccio consiste nella definizione di procedure e flussi dati: la domanda che si pone lanalista cosa fa il sistema?; a livello di astrazione alto il sistema ununica funzionalit, i singoli blocchi dellapplicazione sono task che saranno implementati in singole procedure legate alla specifica soluzione proposta. Questo approccio presenta alcuni problemi: risulta una sostanziale discrepanza tra il concetto di flusso di dati utilizzato dallanalisi e il concetto di gerarchia di compiti utilizzato nella progettazione non esiste uniterazione della progettazione: si adotta un modello a cascata in cui le attivit sono viste come una progressione lineare non si considerano possibili evoluzioni del sistema (non estendibilit) si pone poca attenzione al tema della riusabilit la progettazione dei dati sostanzialmente trascurata. Con lapproccio a oggetti, lanalisi si sviluppa dallinizio del progetto fino allanalisi delle specifiche utente e studio di fattibilit (cosa fare); il design effettua la progettazione logica e fisica del sistema (come fare); limplementazione segue le specifiche definite nelle fasi precedenti e ne permette la validazione. I confini tra le fasi non sono distinti: il centro di interesse sono gli oggetti e le loro interrelazioni.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 8 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Il processo OO iterativo (modello a fontana): lo sviluppo raggiunge un alto livello, poi torna ad un livello basso e risale nuovamente. Lereditariet permette di ridurre costi e tempi di manutenzione, riusabilit e sviluppo di nuove funzioni.

Benefici dellapproccio a oggetti


I blocchi di base dellapplicazione sono entit che interagiscono, modellate come classi di oggetti e legate alla formulazione iniziale del problema. I risultati dellanalisi sono parte integrante del design: queste due fasi sviluppano un modello del dominio del problema. Gli algoritmi e le strutture dati sono demandati alla fase di sviluppo (codifica) con maggiore flessibilit in quanto una diversa implementazione non implica variazioni consistenti alla struttura del sistema. I sistemi sviluppati ad oggetti risultano pi stabili nel tempo: le caratteristiche dei domini variano pi lentamente rispetto alle funzionalit. Si ottiene un alto livello di produttivit. possibile realizzare rapidamente prototipi utili per la certificazione dellanalisi dei requisiti. Un maggior impegno di risorse (tempo) in fase di implementazione delle classi, permette una drastica riduzione dei costi di manutenzione.

Object-oriented analysis
Di che cosa necessita il programma? Determinare le funzionalit del sistema Quali classi saranno presenti? Creare una lista delle classi che sono parte del sistema Qual la responsabilit di ciascuna classe? Distribuire le funzionalit del sistema attraverso le classi individuate

In una buona analisi: le classi sono relativamente piccole e molte sono abbastanza generali da poter essere riusate in futuri progetti la responsabilit e il controllo sono distribuiti ci sono poche assunzioni riguardo al linguaggio di programmazione da usare

Object-oriented design
In che modo la classe gestir le proprie responsabilit? Determinare metodi e attributi di ciascuna classe Quali informazioni sono necessarie alla classe? Progettare algoritmi per implementare le operazioni Come comunicheranno le classi tra loro? Progettare le associazioni

In un buon design: i percorsi di accesso ai dati sono ottimizzati le classi sono raggruppate in moduli

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 9 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

UML
UML un linguaggio, non un metodo. Fornisce i costrutti per le seguenti fasi dello sviluppo dei sistemi software: Analisi dei requisiti tramite casi duso Analisi e progetto OO Modellazione dei componenti Modellazione della struttura e della configurazione.

UNIFIED modelling language


LUML un linguaggi unificante sotto questi aspetti: Ciclo di sviluppo: UML fornisce una sintassi per tutte le fasi del ciclo di sviluppo Domini applicativi: UML utilizzato per modellare sistemi embedded, real time, gestionali, DSS, Linguaggi e piattaforme di sviluppo: UML indipendente dal linguaggio di sviluppo e dalla piattaforma Processi di sviluppo: UML supporta molti processi di sviluppo del software, con particolare predilezione per UP Rappresentazione dei concetti interni: UML cerca di essere consistente e uniforme anche nellapplicazione di un piccolo insieme di concetti interni.

UML e gli oggetti


UML modella sistemi software (e non solo) quali insiemi di oggetti che collaborano tra loro. Un modello UML ha due aspetti: Struttura statica: i tipi di oggetto necessari per modellare il sistema e le loro relazioni Comportamento dinamico: il ciclo di vita degli oggetti e le modalit di collaborazione per fornire le funzionalit richieste al sistema.

Struttura dellUML
UML

Costituenti fondamentali

Meccanismi comuni

Architettura

Entit

Relazioni

diagrammi

Specifiche

Ornamenti

Distinzioni comuni

Meccanismi di estendibilit

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it Costituenti fondamentali Le entit sono gli elementi di modellazione; possono essere suddivise in quattro categorie:

Pagina 10 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Entit strutturali: sono i sostantivi di un modello UML Costituenti (classi, interfaccia, collaborazione, casi duso, classe attiva, fondamentali componente, nodo) Entit comportamentali: i verbi del modello UML (interazioni e macchine a stati) Entit Relazioni diagrammi Entit di raggruppamento: il package; viene utilizzato per raggruppare elementi semanticamente correlati Entit informative: annotazioni che possono essere aggiunte al modello per fornire informazioni particolari (simili a post-it)

Le relazioni mostrano come due o pi entit sono correlate tra loro. Tipo di relazione Dipendenza Sintassi UML Sintassi Descrizione Destinazione
Lelemento sorgente dipende dallelemento destinazione e pu essere influenzato dai cambiamenti eseguiti su di esso Descrizione di un insieme di collegamenti tra oggetti Lelemento di destinazione parte dellelemento sorgente Lelemento di destinazione componente dellelemento sorgente (composto) Lelemento sorgente contiene lelemento di destinazione Lelemento sorgente una specializzazione dellelemento di destinazione pi generale (pu sostituirlo) Lelemento sorgente garantisce di eseguire il contratto specificato dallelemento di destinazione

Sorgente

Associazione Aggregazione Composizione Contenimento Generalizzazione Realizzazione

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it Diagrammi

Pagina 11 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Le entit e le relazioni che vengono create, in una modellazione basata su UML, sono aggiunte al modello. Il modello pertanto larchivio di tutte le entit e le relazioni create per descrivere il comportamento del sistema software che si vuole progettare. I diagrammi sono viste o finestre che consentono di vedere il contenuto del modello. I diagrammi non sono il modello. Esistono tredici diversi tipi di diagrammi UML raggruppati in due categorie principali: i diagrammi che modellano la struttura statica (fissano le entit e le relazioni tra esse) e quelli che modellano la struttura dinamica (fissano il modo in cui le entit interagiscono per genera il comportamento richiesto). Statici
Diagramma delle classi
Descrive struttura la dati degli oggetti del sistema e le loro relazioni. il diagramma pi importante, da cui si pu generare il codice.

Diagramma degli oggetti


Mostra un insieme di oggetti di interesse e le loro relazioni

Diagramma dei package


Mostra i package e le loro relazioni di dipendenza, contenimento e specializzazione

Diagramma dei componenti


Descrive larchitettura software del sistema

Diagramma di deployment
Descrive la struttura hardware e lallocazione dei vari moduli software

Diagramma delle strutture composite


Mostra la struttura interna di classificatori strutturati

Dinamici
Diagramma dei casi duso (funzionale)
Elenca i casi duso e le loro relazioni

Diagramma degli stati


Usa la notazioni degli automi di Harel per descrivere gli stati degli oggetti di una classe

Diagramma di attivit
Descrive le sequenze eventi-azioni-transizioni di una funzione

Diagramma di interazione
Mostra le interazioni tra gli oggetti durante scenari di funzionamento del sistema Diagramma di sequenza Diagramma di comunicazione Diagramma di sintesi dellinterazione Diagramma dei tempi

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it Meccanismi comuni dellUML
Meccanismi comuni

Pagina 12 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Le specifiche sono descrizioni testuali della semantica di un elemento.


Specifiche

Ornamenti

Distinzioni comuni

Meccanismi di estendibilit

Gli ornamenti rendono visibili gli aspetti particolari della specifica dellelemento. importante ricordare che ogni diagramma solamente una vista del modello, per questo motivo possono essere utilizzati o meno gli ornamenti a seconda del diagramma che si sta utilizzando. Le distinzioni comuni descrivono diversi modi di ragionare sul mondo che ci circonda. UML prevede due distinzioni comuni: Classificatore e istanza: UML permette di rappresentare la nozione astratta di unentit e le sue istanze; la prima detta classificatore, le entit specifiche sono appunto dette istanze (le istanze sono rappresentate graficamente sottolineando il tipo)

Interfaccia e implementazione: permette di separare cosa fa un oggetto (interfaccia) da come lo fa (implementazione). Uninterfaccia definisce un contratto di ci che deve essere implementato.

I meccanismi di estendibilit presentati sono: Vincoli: sono frasi di testo racchiuse tra parentesi graffe { } che definiscono una condizione o una regola che riguarda lelemento di modellazione e che deve sempre essere vera; il vincolo limita le caratteristiche dellelemento. UML definisce un linguaggio di vincoli chiamato OCL (Object Constraint Language). Stereotipi: rappresentano variazioni di elementi di modellazioni esistenti, che hanno la stessa forma ma diversi scopi. Permettono di introdurre elementi di modellazione a partire da quelli esistenti. Ne esistono di predefiniti ma possono essere anche introdotti dallutente. I nomi degli stereotipi sono racchiusi tra parentesi angolari e possono essere associati a nuove icone. Propriet: sono valori associati ad un elemento del modello, espresso da una stringa associata allelemento. Profili UML: sono insiemi di stereotipi, valori etichettati e vincoli utilizzati per personalizzare UML.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 13 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Architettura
Alcune definizioni di architettura: Il concetto, pi astratto possibile, che descrive un sistema nel suo ambiente (IEEE) La struttura organizzativa di un sistema, inclusa la sua scomposizione in parti, la loro connettivit, linterazione, i meccanismi e i principi guida che insieme formano il progetto del sistema stesso (The UML Reference Manual, Rimbaugh) Una tecnica molto utilizzata per descrivere unarchitettura il modello 4+1 viste descritto da Philippe Kruchten, in tale modello gli aspetti dellarchitettura sono analizzati secondo quattro diverse viste del sistema: 1. Vista logica: stabilisce la terminologia del dominio del problema sottoforma di insiemi di classi e oggetti; pone enfasi su come gli oggetti e le classi che compongono il sistema implementano il comportamento richiesto 2. Vista dei processi: modella i thread e i processi del sistema sottoforma di classi attive; una variante, orientata ai processi, della vista logica 3. Vista di implementazione: modella file e componenti che costituiscono la base di codice del sistema; illustra la dipendenza tra componenti e la gestione della configurazione dei sottoinsiemi dei componenti, allo scopo di definire il concetto di versione del sistema 4. Vista di deployment: descrive la distribuzione fisica del sistema software sullarchitettura hardware. A queste aggiunta, ed di fondamentale importanza, la: 5. Vista dei casi duso: fissa i requisiti di base di un sistema come un insieme di casi duso, descrive le funzionalit del sistema come vengono percepite dagli utenti, dagli analisti e dagli esecutori del testing; la base per le altre viste. A seconda delle necessit e delle dimensioni di un sistema, si possono usare le diverse viste e i diversi diagrammi. Sistema complesso Viste Casi duso Diagrammi Casi duso Classi/oggetti Componenti Distribuzione Stato Attivit Interazione Sistema medio Logica Dei processi Sistema piccolo Implementativa Deplyment

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 14 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

UP
Un processo di sviluppo del software (Software Development Process, SDP), detto anche processo di ingegneria del software (Software Engineering Process, SEP) definisce il chi, cosa, quando e come dello sviluppo di un software. Gli autori di UML hanno ideato il processo unificato per lo sviluppo del software (Unified Software Development Process, USDP) comunemente chiamato Unified Process.

Visione e requisiti

Processo di ingegneria del software

Software

Rational Unified Process (RUP) una versione commerciale e pi completa di UP creata da IBM. Entrambe le metodologie modellano il chi, il cosa, il quando, seppur in modalit leggermente differenti. Unified Process utilizza: Il concetto di risorsa, per modellare il chi: una risorsa descrive il ruolo che un individuo, o un gruppo di individui, ha allinterno di un progetto I concetti di attivit e manufatti, per modellare il cosa: le attivit sono compiti che vengono eseguiti dagli individui e dai gruppi coinvolti nel progetto; le attivit possono essere scomposte in sottoattivit; i manufatti descrivono materiali, di qualunque natura, richiesti o prodotti dal progetto (codice, eseguibili, standard, documentazione, ) Il quando modellato utilizzando i flussi di lavoro: rappresentano una sequenza di attivit correlate che vengono eseguite dalle risorse umane (in RUP i flussi di lavoro di alto livello sono detti discipline); i flussi di lavoro possono essere scomposti in dettagli che descrivono ruoli, attivit e manufatti coinvolti.

Come istanziare UP su un progetto


Il processo di istanziazione, necessario per ciascun progetto, consiste nella definizione e integrazione di: Standard per il gruppo di lavoro Modelli di documento standard Strumenti: compilatori, gestione della configurazione, Archiviazione: gestione dei difetti, gestione del progetto, Modifiche del ciclo di vita: ad esempio strumento per il controllo del livello di qualit,

In qualsiasi progetto di ingegneria del software necessario investire una certa quantit di tempo e risorse per listanziazione.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 15 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Assiomi dellUP
UP basato su tre assiomi fondamentali: pilotato dai casi duso (definiti dai requisiti di sistema) e dai fattori di rischio incentrato sullarchitettura: prevede la descrizione degli aspetti strategici del sistema, della sua composizione e dellinterazione tra i componenti e il posizionamento dei nodi hardware iterativo e incrementale: il progetto scomposto in sottoprogetti (iterazioni), ognuno dei quali porta al rilascio di specifiche funzionalit in modo tale da costruire il software in maniera incrementale iterando le fasi sviluppo.

Ogni sottoprogetto, in UP, contiene tutti gli elemento di un tipico progetto di sviluppo software: Pianificazione Analisi e progettazione Costruzione Integrazione e test Rilascio (interno o esterno).

Ogni sottoprogetto detto iterazione e porta al rilascio di una baseline che comprende una versione parzialmente completa del sistema finale e la relativa documentazione di progetto. La differenza tra due baseline consecutive detta incremento. Esistono cinque fondamentali flussi di lavoro che specificano quali attivit debbano essere svolte in ciascuna iterazione: Requisiti: fissa ci che il sistema dovrebbe fare Analisi: mette a punto i requisiti e aggiunge loro struttura Progettazione: concretizza i requisiti in unarchitettura del sistema Implementazione: costruisce il software Test: verifica che limplementazione rispetti i requisiti.

possibile pianificare i flussi di lavoro delle diverse iterazioni in modo che alcune fasi vengano affrontate in parallelo per ridurre i tempi di rilascio e ottimizzare le risorse: questa attivit richiede maggiore sforzo per realizzare una migliore progettazione.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 16 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Struttura dellUP
UP struttura il ciclo di vita del progetto in quattro fasi: Avvio Elaborazione Costruzione Transizione Ogni fase, che pu essere composta da una o pi iterazioni, si conclude con una milestone che un insieme di condizioni da soddisfare.
Avvio Obiettivi del ciclo di vita Iterazione 1 (RAPIT) Elaborazione Architettura del ciclo di vita Iterazione 2 (RAPIT) Iterazione 3 (RAPIT) Costruzione Capacit operativa iniziale Iterazione 4 (RAPIT) Iterazione 5 (RAPIT) Transizione Rilascio del prodotto Iterazione 6 (RAPIT)

Fase Obiettivi

Avvio Far decollare il progetto: Stabilire la fattibilit (eventualmente tramite un prototipo tecnico o una prova di fattibilit per validare i requisiti iniziali) Creare un caso di business per dimostrare che il progetto apporter un beneficio quantificabile Fissare i requisiti essenziali per definire lambito del sistema Identificare i rischi pi critici Capoprogetto e architetto del sistema Si

Elaborazione Creare una baseline eseguibile Prefezionare la valutazione dei rischi Definire attributi di qualit Fissare i casi duso relativi all80% dei requisiti funzionali Creare un piano dettagliato della fase di costruzione Formulare una valutazione iniziale di risorse, tempo, strumenti e costi

Costruzione Completare i requisiti, lanalisi e la progettazione e fare evolvere la baseline eseguibile generata nellelaborazione. Richiede che si mantenga lintegrit del sistema.

Transizione Rilascio del software agli utenti, dopo il beta test. Correzione dei difetti Preparazione dei siti per il rilascio Adattamento del software per il corretto funzionamento presso i siti degli utenti Modifica a fronte di problemi non previsti Creazione manuale utente e documentazione Consulenza agli utenti Riepilogo di fine progetto

Risorse Flussi di lavoro Requisiti

Analisi Progettazione Implementazione Solo in caso di prototipi o studi di fattibilit

Fissare la maggior parte di requisiti e definire lambito del sistema Definire cosa deve essere costruito Creare unarchitettura stabile Costruire una baseline eseguibile

Portare alla luce i requisiti mancanti Ultimare il modello di analisi Ultimare il modello di progettazione Costruire la capacit operativa iniziale Verificare la capacit operativa iniziale Il sistema software deve essere completo e predisposto per il beta test degli utenti: Stabilit e qualit del software sufficienti per il rilascio agli utenti Accettazione del rilascio del software Accettazione dei costi reali (confrontati con i costi previsti)

Non applicabile

Non applicabile Rivedere il modello in caso di problemi durante il beta test Adattare il software al rilascio presso i siti utenti e correggere difetti scoperti durante il test Beta test e test di accettazione eseguito presso i siti utente Milestone finale: Beta test Modifiche necessarie Rilascio concordato Utilizzo del prodotto Pianificazione del supporto Accordo su strategie di supporto

Test Milestone

Non applicabile Obiettivi del ciclo di vita: Obiettivi di progetto Ambito di progetto Requisiti principali Stime di costi e tempi Caso di business Valutazione dei rischi Studio di fattibilit Schema di archiettetura Possono essere realizzati manufatti relativi agli obiettivi ove portino valore aggiunto al progetto.

Verificare la baseline eseguibile Architettura del Ciclo di vita: Baseline robusta ed eseguibile Dimostrazione dellidentificazione e risoluzione dei rischi principali Visione dinsieme stabile Revisione rischi Revisione caso di business Stima realistica dei tempi, costi e risorse Approvazione pianificazione di progetto Caso di business verificato Accordo firmato tra le parti

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 17 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Flusso di lavoro dei requisiti


Il flusso di lavoro dei requisiti deve permettere di capire cosa si vuole ottenere. Fa naturalmente parte delle prime fasi del ciclo di vita del progetto in quanto non possibile realizzare qualcosa se non si sa cosa realizzare. Si tratta di un processo di negoziazione in quanto spesso si individuano requisiti contrastanti (in quanto, ad esempio, espressi da diversi gruppi di utenti). I diagrammi dei casi duso UML permettono di descrivere bene cosa deve fare il sistema, tuttavia necessar io descrivere anche altri requisiti non-funzionali che descrivono quali siano i vincoli che il sistema deve rispettare.

Meta-modello della specifica dei requisiti


Il modello di Specifica dei Requisiti del Software (Software Requirements Specification, SRS) contiene un modello dei requisiti e un modello dei casi duso; si tratta di due metodi differenti e complementare per fissare i requisiti. Il modello dei requisiti pu contenere sia requisiti funzionali che non funzionali. Il modello dei casi duso pu contenere diversi package, attori, e relazioni.

Flusso di lavoro dei requisiti


Il flusso di lavoro standard di UP prevede le seguenti attivit: i. ii. iii. iv. v. Individuazione di attori e casi duso (svolta dallanalista di sistema) dalla quale dipende Assegnazione delle priorit ai casi duso (svolta dallarchitetto) dalla quale dipende Descrizione di ogni caso duso (svolta dallanalista dei casi duso) dalla quale dipendono Strutturazione del modello dei casi duso (svolta dallanalista di sistema) e Prototipazione dellinterfaccia utente (svolta dal progettista dellinterfaccia utente).

Per descrivere meglio e gestire in modo completo tutti i requisiti, tale flusso esteso con: vi. vii. viii. ix. Individuazione dei requisiti funzionali (svolta dallingegnere dei requisiti) Individuazione dei requisiti non funzionali (svolta dallingegnere dei requisiti) Assegnazione delle priorit ai requisiti (svolta dallingegnere dei requisiti) Estrazione dei casi duso dai requisiti (svolta dallarchitetto).

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it Importanza dei requisiti

Pagina 18 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

La raccolta incompleta dei requisiti e la mancanza di coinvolgimento degli utenti sono le principali cause di fallimento dei progetti software, entrambi sono effetto del fallimento dellingegneria dei requisiti.

Definire i requisiti
Un requisito pu essere definito come una specifica che deve essere implementata. I requisiti funzionali definiscono il comportamento che il sistema dovrebbe avere. I requisiti non funzionali definiscono propriet o vincoli specifici del sistema. UML non definisce come scrivere i requisiti e si occupa di essi solo tramite il meccanismo dei casi duso che potrebbe non essere sufficiente per descrivere tutti i requisiti. Ogni requisito pu essere descritto e formalizzato con un modello semplice: Identificatore univoco Identificazione del sistema Funzione che il sistema deve svolgere <id> il <sistema> dovr <funzione> Organizzare i requisiti utile separare i requisiti funzionali da quelli non funzionali. possibile organizzare i requisiti in una tassonomia, ovvero una gerarchia di tipi utile a classificare i requisiti e renderli meglio utilizzabili permettendo di lavorare con essi in maniera pi efficace.

Requisiti funzionali (esempio)


Clienti Prodotti Ordini Canali di vendita Pagamenti

Requisiti non funzionali (standard)


Prestazioni Capacit Disponibilit Conformit agli standard Sicurezza

Ogni requisito pu avere un insieme di attributi che fornisce informazioni aggiuntive (metadati) sul requisito stesso.

...

Ogni attributo ha un nome che lo descrive e un valore. Lattributo pi comune la priorit che indica la precedenza o limportanza del requisito rispetto agli altri. Uno schema comune per assegnare le priorit linsieme dei criteri MoSCoW: Must have: Should have: Could have: Want to have: requisiti obbligatori requisiti importanti, possono essere omessi requisiti opzionali (da realizzare se c tempo) requisiti che possono essere rimandati a versioni successive.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 19 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

MoSCoW confonde importanza (che una caratteristica stabile nel tempo) e precedenza (che pu variare in base alle disponibilit durante la realizzazione). Uno schema alternativo a MoSCoW definito da RUP: Attributo Stato Valori Proposed (proposto) Approved (rifiutato) Incorporated (incorporato) Critical (critico) Vantaggi Important (importante) Useful (utile) Sforzo Rischio Stabilit Versione destinazione Giorni persona / Punti funzione Alto / Medio / Basso Alta / Media / Bassa Versione

requisiti ancora in fase di discussione, non concordati requisito rifiutato requisito implementato in una particolare versione deve essere implementato, altrimenti il sistema non sar accettabile potrebbe essere omesso, influenza per lusabilit e la soddisfazione delle parti interessate potrebbe essere omesso senza alcun impatto significativo sullaccettabilit del sistema indica una stima del tempo e delle risorse necessarie per implementare la caratteristica valutata indica il rischio implicito nellaggiunta della caratteristica indica la valutazione della probabilit che il requisito cambi indica la versione del prodotto in cui il requisito dovrebbe essere implementato

Individuare i requisiti Lingegneria dei requisiti inizia, solitamente, con un documento di visione che sottolinea ci che il sistema far e quali vantaggi porter ad un insieme di parti interessate: tale documento, prodotto dallanalista in fase di avvio dellUP, deve fissare gli obiettivi essenziali del sistema dal punto di vista delle parti interessate. Il contesto che il sistema deve modellare include: Utenti diretti del sistema Altre parti interessate (manager, gestori, installatori, ) Altri sistemi software e hardware che interagiscono con il sistema Vincoli contrattuali e legali Vincoli tecnici Obiettivi di business.

Lo scopo della raccolta dei requisiti consiste nel fissare e definire una mappa precisa del modello che si vuole poi realizzare. Questa mappa viene creata (Noam Chomsky, Syntactic Structures, 1975) tramite tre processi: Rimozione: linformazione viene scartata Distorsione: linformazione viene modificata tramite i meccanismi della creazione e dellallucinazione Generalizzazione: linformazione viene incorporata in una regola, assioma o principio che riguarda i concetti di verit e falsit. necessario riconoscere questi processi e mettere in discussione i requisiti descritti chiedendosi quali processi sono stati attuati e se si correttamente descritta la realt.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it Interviste

Pagina 20 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

il modo pi diretto per raccogliere i requisiti. Nelle interviste, meglio se individuali, necessario ascoltare ignorando di avere (quando la si immagina) una soluzione gi definita. necessario porre domande indipendenti dal contesto per incoraggiare lintervistato a parlare del problema. Un contesto informale potrebbe migliorare la qualit dei dati raccolti durante lintervista perch permette allintervistato e allintervistatore di rilassarsi e aprirsi maggiormente. utilissimo prendere appunti su carta, magari utilizzando mappe mentali. Meglio non utilizzare portatili che possono distrarre entrambe le parti ed intimidire lintervistato. Al termine dellintervista possibile analizzare le informazioni e costruire requisiti candidati. Questionari Non sostituiscono le interviste, anzi, il metodo migliore costruire i questionari a fronte dei dubbi emersi durante e dopo le interviste. Sono particolarmente utili per ottenere risposte specifiche a domande chiuse. Possono essere distribuiti ad un pubblico pi ampio e possono pertanto migliorare la comprensione dei requisiti. Workshop sui requisiti Partecipanti: committenti, ingegnere dei requisiti, parti interessate, esperti del dominio. Brainstorming: 1. Spiegare ai partecipanti che si tratta di una sessione di brainstorming 1.1. Tutte le idee sono considerate buone 1.2. Le idee vengono registrate ma non dibattute: non si discute nulla ci si limita a scrivere e si prosegue, lanalisi rimandata 2. Chiede ai partecipanti di assegnare un nome ai requisiti fondamentali per il sistema 2.1. Scrivere ogni requisito su un post-it 2.2. Attaccare il post-it ad una parete o ad una lavagna 3. possibile scegliere di prendere in considerazione una seconda volta i requisiti identificati annotando ulteriori attributi per ciascuno Al termine del workshop necessario fissare i requisiti e condividerli per eventuali commenti.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 21 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Modellazione dei casi duso


La modellazione dei casi duso una forma dingegneria dei requisiti che prevede tipicamente i seguenti passi: 1. Individuare un potenziale confine del sistema 2. Individuare gli attori 3. Individuare i casi duso a. Specificare i casi duso b. Identificare le principali sequenze degli eventi alternative. Il modello dei casi duso costituito da quattro componenti: 1. 2. 3. 4. Attori: i ruoli assunti dalle persone e dalle cose che usano il sistema Casi duso: quello che gli attori possono fare con il sistema Relazioni: relazioni tra attori e casi duso Confine del sistema: un rettangolo disegnato intorno ai casi duso per indicare il confine del sistema.

Il modello dei casi duso costituisce linput pi importante per la modellazione delle classi.

Individuare attori e casi duso


Per individuare attori e casi duso si utilizzano, quali input: Il modello di business: se disponibile costituisce uneccellente fonte di requisiti Il modello dei requisiti: documento prodotto dallanalisi dei requisiti Elenco delle feature: insieme di potenziali requisiti che pu assumere la forma di documento di visione o simili.

Loutput di questa modellazione genera il modello dei casi duso e il glossario di progetto.

Modello di business Analista di sistema Modello dei requisiti

Modello dei casi duso (schematico)

Elenco delle feature

Individuare attori e casi duso

Glossario di progetto

Subject: il confine di sistema


Lindividuazione del confine di sistema (subject) ha un notevole impatto sui requisiti e quindi sullintero progetto: si tratta di definire cosa fa parte e cosa non fa parte del sistema. Il subject, definito da chi o cosa usa il sistema (attori) e dalle funzioni offerte (casi duso), rappresentato con un rettangolo etichetta con il nome del sistema. Gli attori sono posizionati allesterno del rettangolo e i casi duso allinterno.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 22 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Attori
Un attore identifica il ruolo che unentit esterna assume quando interagisce direttamente con il sistema. Possono essere utilizzati (UML 2) per rappresentare altri subject e rappresentare i collegamenti tra diversi modelli dei casi duso. Gli attori possono essere rappresentati come icone della classe stereotipata attore o come icona a forma di uomo stilizzato. Solitamente si utilizza licona a forma di uomo stilizzato per rappresentare ruoli interpretati da persone e licona stereotipata per rappresentare ruoli interpretati da altri sistemi. Gli attori sono sempre esterni ai sistemi. I sistemi possono contenere una rappresentazione interna degli attori (es: cliente un attore, ma un software di vendita gestisce la sua rappresentazione interna). Individuare gli attori Per individuare gli attori possibile provare a rispondere a queste domande. Chi o cosa usa il sistema? Quale ruolo rivestono durante linterazione con il sistema? Chi installa il sistema? Chi o cosa avvia e ferma il sistema? Chi effettua la manutenzione del sistema? Quali altri sistemi interagiscono con il sistema? Chi ottiene informazioni dal sistema e chi ne fornisce? Esistono funzioni che sono eseguite a intervalli, orari o date prestabiliti?
Attore ruolo

importante ricordare che: Gli attori sono sempre esterni al sistema: non possono essere controllati Gli attori interagiscono direttamente con il sistema: aiutano a fissare il subject Gli attori rappresentano ruoli generici non persone o cose specifiche Una persona pu rivestire ruoli diversi, contemporaneamente o meno Ogni attore deve essere identificato con un nome breve, significativo nel domino applicativo Ogni attore deve essere caratterizzato da una breve descrizione che lo definisca Licona di attore pu essere caratterizzata da una sottosezione che elenca attributi ed eventi.

Attore ruolo

In casi particolari possibile modellare il tempo come un attore (ad esempio per modellare procedure periodiche).

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 23 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Casi duso
I casi duso sono definiti da The UML Reference Manual come la specifica di una sequenza di azioni, incluse eventuali sequenze alternative e sequenze di errore, che un sistema, un sottosistema o una classe pu eseguire interagendo con attori esterni. Un caso duso qualcosa che un attore vuole che il sistema faccia. Essi sono sempre avviati da attori e sono sempre descritti dal punto di vista degli attori. Caso duso Individuare i casi duso Il modo migliore per individuare i casi duso consiste nel ragionare su cosa fanno gli attori per utilizzare il sistema. Ad ogni caso duso individuato si assegna una frase breve composta principalmente da un verbo. possibile che si individuino, assieme ai casi duso, attori non previsti: lindividuazione dei casi duso effettuata iterativamente e per approssimazioni successive. necessario individuare solo il nome: i dettagli sono completati solo successivamente. Per individuare i casi duso possibile aiutarsi con le seguenti domande: Quali funzioni si aspetta dal sistema ciascun attore? Il sistema archivia e recupera informazioni? Quali attori provocano queste azioni? Cosa accade quando il sistema cambia stato (avvio, interruzione, )? Esistono notifiche verso gli attori? Esistono eventi esterni che producono effetti sul sistema? Chi o cosa notifica tali eventi? Il sistema interagisce con un sistema esterno? Il sistema genera report?

Il diagramma dei casi duso dunque costituito da: Il subject, rappresentato da un rettangolo Gli attori, posti allesterno del subject I casi duso, allinterno del subject Le relazioni, rappresentate da linee solide che collegano gli attori ai casi duso loro inerenti.

Glossario di progetto
uno dei documenti pi importanti, rappresenta il dizionario dei principali termini del dominio e le relative definizioni. Dovrebbe essere comprensibile a tutti i soggetti coinvolti allo scopo di aiutare la comprensione del linguaggio specifico del sistema, per questo motivo, tra laltro, il glossario di progetto deve risolvere i casi di: Sinonimia: individuando quali concetti sono rappresentati da pi di un vocabolo e scegliendo un vocabolo per rappresentare sempre il concetto allinterno del progetto Omonimia: individuando eventuali concetti diversi rappresentati dallo stesso vocabolo e introducendo nuovi vocaboli per evitare fraintendimenti.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 24 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Descrivere i casi duso


Dopo aver individuato i casi duso possibile iniziare a descriverli brevemente producendo un modello con maggiori dettagli. La descrizione dei casi duso pu essere pi o meno dettagliata e non definita in UML n oggetto di standard specifico (tuttavia le aziende devono definire un proprio standard per rendere utile la fatica profusa nella definizione dei casi duso), di seguito si presenta un modello tipico. Nome del caso duso Identificatore del caso duso Breve descrizione Attori principali Attori secondari Precondizioni
Sempre scritto con lettere maiuscole e minuscole, inizia con una lettera maiuscola. Dovrebbe essere un verbo o un predicato verbale breve ma descrittivo e comprensibile dai lettori. Deve essere univoco allinterno del modello. Il nome del caso duso, pur essendo univoco, potrebbe cambiare nel tempo; per questo motivo si definisce un identificatore fisso (solitamente numerico). Un paragrafo che riassume brevemente lobiettivo del caso duso; deve fissarne lessenza: i vantaggi che ne traggono i suoi attori. Sono gli attori che avviano il caso duso. Ogni caso duso avviato da un singolo attore alla volta: in momenti diversi, diversi autori possono avviarlo. Sono attori che interagiscono con il caso duso dopo che stato avviato. Rappresentano vincoli sullo stato del sistema prima che il caso duso possa iniziare lesecuzione; se non sono soddisfatti il caso duso non p u essere avviato. Indicano ci che deve essere vero prima che il caso duso sia avviato. buon uso scrivere sempre precondizioni, eventualmente indicando nessuna ove non siano previste. Vincolano lo stato del sistema al termine del caso duso. buon uso scrivere sempre postcondizioni, eventualmente indicando nessuna ove non siano previste. Elenca i passi che compongono il caso duso nello scenario principale (mondo perfetto). Inizia sempre con lattore principale che fa qualcosa: 1. Il caso duso inizia quando un attore fa funzione I passi del caso duso sono solitamente descritti nella forma: <numero> - <qualcosa> <qualche azione> I passi devono essere precisi e non ambigui: devono definire chi, cosa, quando, dove. Possono esistere ramificazioni nella sequenza principale: tramite la parola chiave se possibile definire ramificazioni semplici ovvero azioni svolte nel caso in cui lespressione (booleana) che segue il se sia vera. Tramite la parola chiave per (for) possibile modellare una ripetizione (ciclo) per un certo numero di volte Tramite la parola chiave fintantoch (while) possibile modellare una ripetizione fino a quando una certa condizione (booleana) vera. Le sequenze alternative possono modellare percorsi alternativi che rappresentano errori, ramificazioni o interruzioni della sequenza principale. Solitamente si indica un elenco di sequenze alternative assegnando un nome e si descrivono a parte tali sequenze con un modello simile a quello dei casi duso ad eccezione del fatto che non esse non possono avere ulteriori sequenze alternative. Il nome definito come il nome della sequenza principale, seguito dai due punti : e dal nome della sequenza alternativa Lidentificatore costituito dallidentificatore della sequenza principale seguito da un punto e da un identificatore della sequenza alternativa. La sequenza alternativa pu essere attivata: Al posto della sequenza principale (dallattore principale) e la sostituisce integralmente Ad un certo passo della sequenza principale (e potrebbe non ritornarvi) In un qualsiasi momento dipendente da determinate azioni dellutente. Per individuarle possibile, per ogni passo della sequenza principale, valutare possibili alternative, errori, interruzioni.

Postcondizioni Sequenza degli eventi principale

Sequenza degli eventi alternativa

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 25 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Mappatura dei requisiti


importante incrociare il contenuto del modello dei requisiti e del modello dei casi duso per verificare che tutti i requisiti siano coperti dai casi duso. Tramite UML possibile associare ad un caso duso un insieme di requisiti funzionali inserendo i loro identificativi in una lista di valori etichettati. Manualmente possibile creare una matrice di mappatura dei requisiti: una semplice griglia che riporta gli identificativi numerici dei requisiti su un asse e i nomi dei casi duso (e/o i loro identificativi) sullaltro. Si segnano poi le caselle corrispondenti ai requisiti corrisposti dai singoli casi duso. Se rimangono requisiti senza segni significa che mancano le definizioni di certi casi duso, viceversa significa che non sono stati individuati tutti i requisiti. Casi duso Requisiti R1 R2 R3 R4 Rm UC1 UC2 Caso duso mancante Requisito non individuato UC3 UC4 UCn

Casi di applicazione della modellazioni dei casi duso


I casi duso sono il miglior modo di fissare i requisiti se: Il sistema dominato da requisiti funzionali Il sistema fornisce diverse funzionalit a molti tipi di utente (esistono molti attori) Il sistema ha molte interfacce con altri sistemi (esistono molti attori) Viceversa, non sono molto indicati se: Il sistema dominato da requisiti non funzionali Il sistema ha pochi tipi di utente Il sistema ha poche interfacce con altri sistemi.

Modello dei casi duso (schematico)

Specifiche del caso duso Caso duso (dettaglaiato)

Glossario di progetto

Descrivere un caso duso

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 26 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Modellazione dei casi duso: tecniche avanzate


Generalizzazione tra attori
Quando due o pi attori, allinterno del diagramma dei casi duso, danno inizio agli stessi casi (per la maggior parte), probabilmente possibile e consigliabile generalizzare gli attori descrivendo un attore (solitamente astratto) generalizzato. In questo modo si semplifica il modello, chiarificandolo. possibile poi che alcuni attori specializzati siano attori primari di specifici casi duso. possibile verificare che un attore specializzato possa essere utilizzato per qualsiasi caso duso del suo attore generalizzato. Gli attori specializzati ereditano tutte le relazioni con i casi duso dellattore generalizzato. Un esempio.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 27 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Generalizzazione tra casi duso


La generalizzazione tra casi duso utilizzata quando esistono uno o pi casi duso che sono specializzazione di un caso duso pi generalizzato. I casi duso figli: ereditano le caratteristiche dal caso duso genitore possono aggiungere nuove caratteristiche possono ridefinire alcune caratteristiche ereditate.

La seguente tabella indica quali caratteristiche possono essere ereditate, aggiunte e ridefinite. Modello dei requisiti del caso duso Relazione Punto di estensione (padre) Precondizione Postcondizione Passo della sequenza principale Sequenza alternativa Ereditare Aggiungere Ridefinire

Per indicare che un passo ereditato dal padre, solitamente si indica, di fianco al numero di sequenza, fra parentesi il numero del passo del caso padre; per indicare che un figlio ridefinisce il passo, si indica fra parentesi il numero del passo padre preceduto dalla lettera o (overridden). Allo scopo di evitare di dover mantenere la consistenza di ereditariet allaggiornamento dei vari casi duso, si pu utilizzare una tecnica per cui il caso duso padre non ha la sequenza degli eventi principale, ma solo una breve descrizione. I casi figli avranno ognuno la propria implementazione della sequenza principale.

Include
Se un caso duso (o un frammento di un caso duso) pi volte referenziato da altri casi duso allinterno del modello, allora possibile utilizzare la relazione con semantica include. Un caso duso base include un caso duso dinclusione. Il caso duso di inclusione pu essere completo e istanziabile da un attore, oppure parziale (si parla allora di frammento di comportamento) e in questo caso non pu essere avviato da un attore. Il caso duso base non completo senza tutti i suoi casi dinclusione.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 28 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Estende
La relazione estende fornisce un modo di aggiungere un comportamento a un caso duso esistente. Il caso duso base completo e non conosce il caso duso di estensione; fornisce per indicazioni su quali possono essere i propri punti di estensione. Il caso duso di estensione solitamente incompleto e non pu essere istanziato. La relazione estende deve specificare uno o pi punti di estensione, in caso contrario si assume che la relazione riguarda tutti i punti di estensione. Il caso duso di estensione deve avere tanti segmenti inseribili quanti sono i punti di estensione specificati nella relazione. consentito avere due casi duso di estensione, se ci accade lordine di esecuzione dei due segmenti indeterminato. anche possibile estendere i casi duso in maniera condizionale: si indicano espressioni booleane a seconda del cui stato di verit sar esteso o meno il caso duso.

Estensione semplice

Estensione multipla, indicazione del punto di estensione

Estensione condizionale

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 29 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Quando usare le tecniche avanzate


Le tecniche avanzate devono essere utilizzate solo se semplificano il modello dei casi duso: si ricorda che il modello dei casi duso deve essere leggibile da tutte le parti interessate. Le parti interessate solitamente capiscono facilmente attori e casi duso, con poca formazione. Le parti interessate hanno maggiori difficolt a comprendere la generalizzazione tra attori. Un uso eccessivo di relazioni include pu rendere i modelli difficili da comprendere. Le parti interessate difficilmente comprendono il concetto di relazione estende, anche con molte spiegazioni. Molti modellatori non comprendono la semantica della relazione estende. La generalizzazione tra casi duso andrebbe evitata, tranne quando si utilizzano casi duso astratti.

Come scrivere i casi duso


Mantenere i casi duso brevi e semplici Semplificare il testo, eliminare qualsiasi dettaglio di progettazione, scorporare in casi duso pi piccoli o sequenze alternative. Cosa e come I casi duso servono per stabilire cosa gli attori richiedono che il sistema faccia e non come il sistema dovrebbe farlo (descritto invece dalla progettazione). Evitare la scomposizione funzionale possibile immaginare i casi duso ad alto livello e, via via, scomporli in casi duso pi semplici fino a quelli di dettaglio. La modellazione dei casi duso cos fatta presenta aspetti inaccettabili: Il modello si focalizza sulla strutturazione dei requisiti in modo artificiale (esistono diversi tipi di scomposizioni possibili) anzich concentrarsi sulla raccolta dei requisiti Il modello descrive il sistema come un insieme di funzioni annidate mentre i sistemi Object Oriented sono insiemi di oggetti cooperanti che inviano messaggi (incongruenza concettuale) Solo i livelli pi bassi dei casi duso hanno specifiche interessanti: i livelli pi alti non aggiungono nulla al modello in termini di raccolta dei requisiti Il modello pi complesso e meno comprensibile (troppi casi astratti, troppe relazioni include). Vanno sempre evitate gerarchie pi profonde di due livelli.

Progettazione di sistemi informatici (41492)


Prof. Stefano Rizzi - stefano.rizzi@unibo.it Appunti di Nicola Gentili nicola.gentili2@studio.unibo.it

Pagina 30 di 32 A.A. 2013/2014


ultimo aggiornamento: 22/10/2013 01:25

Ingegneria del software Esercitazioni