Modello a cascata Sviluppo iterativo del SW Unified Modeling Language ... - Di … ·...

Unified Modeling Language

Ing. Gianluca Di Tomassiwww.ditomassi.it

Unified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 2

Sommario

� Modello a spirale� Modello incrementale� Sviluppo iterativo del SW� Modello a cascata

� Modelli del processo SW

� Activity Diagram� Use case Diagram

� I diagrammi di UML� Un po’ di storia e gli obiettivi

� Unified Modeling Language

� Interaction Diagram� Class Diagram

� Package Diagram� State Transaction Diagram

� Component Diagram

� Deployment Diagram

� XP (eXtreme Programming)� RUP (Rational Unified Process)

� Alcune metodologie per lo sviluppo di un progetto applicat.


Modelli del processo SW

Ciclo di vita di un progetto software = Modello delle attività di sviluppo e dell’operare il sistema informatico.Tipi di modelli:Il modello sequenziale lineare (“modello a cascata”)Il modello basato sulla prototipazioneIl modello RAD (Rapid Application Development)Modelli evolutivi� Il modello incrementale� Il modello a spirale� Il modello ad assemblaggio di componenti

Il modello dei metodi formaliElementi che influiscono sulla scelta del modello del processo:la natura del progetto e dell’applicazionele competenze specifiche e l’esperienza acquisita in progetti precedenti

dai membri del team di sviluppoi metodi e strumenti che si vogliono utilizzarei controlli e prodotti richiesti.


Modello a cascata

Strutturazione e modellazione del sistema e dei dati (livello sistema)

Analisi dei requisiti sw. Progettazione Codifica Collaudo

Il software è una parte di un sistema più ampio. Sono necessarie un’analisi e una progettazione di alto livello per raccogliere tutti i requisiti, da cui il software utilizza solo una parte.

dominio delle informazioni, funzionalità, comportamento, prestazioni, interfacce

strutture di dati, architettura del software, interfacce, algoritmi delle operazioni

codice

Problemi:• i progetti reali non si conformano allo schema sequenziale • ogni modifica nello schema può causare confusioni• non può essere governata l’incompletezza dei requisiti• versione funzionante solo verso la fine del progetto• “stati bloccanti” per colpa della sincronizzazione tra le attività o tra i membri del team


Sviluppo iterativo del SW

1. Non c’è tempo per una versione completa però dobbiamo uscire sul mercato.2. Esiste un nucleo di requisiti di sistema ma i dettagli delle estensioni non esistono ancora. Soluzione: modello di processo per un prodotto che evolve nel tempo

Vantaggi dello sviluppo iterativo•È pianificato e gestito•È prevedibile •Permette variazioni dei requisiti più facilmente•È basato su prototipi eseguibili evolutivi e non solo documentati•Implica il cliente nell’arco dell’intero processo•È guidato da rischi

Definire l’output del sistema

Specificare l’incremento del

sistema

Costruire l’incremento del

sistema

Collaudare l’incremento del

sistema

Rilasciare l’incremento del

sistema

Sistema ècompleto?

Completare il rilascio del

sistema


Modello Incrementale

Strutturazione del sistemae dei dati

Analisi Proget tazione

Codifica Collaudo

Stadio 1

Consegna dello stadio 1


Codifica CollaudoStadio 2 Consegna dello stadio 2





Utile quando la disponibilità del personale èinsufficiente a garantire l’implementazione completa. Si comincia con un piccolo team. Il team accresce se l’accoglienza è positiva.


Modello a spirale

Il modello abbina la natura iterativa della prototipazione e gli aspetti controllati e sistematici del modello sequenziale.

Sei attività portanti(task region):

Pianificazione

Analisi dei rischi

Strutturazione

Costruzione e rilascio

Comunicazioni con il cliente

Valutazione da parte del cliente

Asse dei punti di entrata

Progetti di sviluppo di nuove ideeProgetti di sviluppo di un nuovo prodottoProgetti di miglioramento di un prodottoProgetti di manutenzione di un prodotto


Sommario













Un pò di storia

UML nasce per soddisfare il bisogno di un linguaggio di modellazione per sistemi complessi che sia semplice e capace di affrontare tutte le problematiche del progetto di tali sistemi complessi

Lo sviluppo di UML comincia nell’ottobre del 1994

UML e’ il prodotto di una unificazione dei metodi

1. Booch espressivo durante il progetto e adatto ad applicazioni engineering-intensive (Autore Grady Booch)

2. OMT (Object Modeling Tecnique) è un linguaggio di modellazione per l’analisi e adatto a sistemi data-intensive

2. OOSE (Object Oriented Software Engineering) orientato agli use-case � fornisce un eccellente supporto all’analisi dei requisiti


Un pò di storia


Che cosa è UML

1. E’ un linguaggio per specificare, costruire, visualizzare e documentare manufatti sia di sistemi software, sia di processi produttivi e altri sistemi non strettamente software.

2. Rappresenta una collezione di best practices di ingegneria, dimostratesi vincenti nella modellazione di vasti e complessi sistemi

3. Permette di visualizzare, per mezzo di un formalismo rigoroso, “manufatti” dell’ingegneria, consentendo di illustrare idee, decisioni prese, e soluzioni prese

4. Favorisce, inoltre, la divulgazione delle informazioni, in quanto standard internazionale “de facto” non legato alle singole imprese (Dal 1997 standard effettivo adottato dall’OMG)

5. Permette di realizzare modelli potranno essere implementati con diversi linguaggi di programmazione


Che cosa NON è UML

1. Non è un linguaggio di programmazione visuale

2. Non è un processo di sviluppo (cioè non dice “prima bisogna fare questa attività, poi quest’altra”)

3. UML include suggerimenti utili per coloro che si occupano di realizzare dei tool di supporto, ma non stabilisce ogni necessario particolare.


Obiettivi dell‘UML

1. Fornire agli utenti un linguaggio di modellazione visuale pronto ad essere utilizzato per sviluppare e scambiare modelli espressivi

2. Fornire meccanismi di estensione e specializzazione al fine di accrescere i concetti presenti nel nucleo.

3. Supportare specifiche che risultino indipendenti da un particolare linguaggio di programmazione o processo di sviluppo.

4. Fornire le basi formali per comprendere il linguaggio di modellazione.

5. Incoraggiare la crescita del mercato dei tool Object Oriented

6. Supportare concetti di sviluppo di alto livello come componenti, collaborazioni, framework e pattern.

7. Integrare le best practices.


Generalità

� Le iconeIn UML vi sono quatto costrutti grafici:

� I simboli bidimensionali

� I collegamenti

� Le stringhe


I diagrammi UML

� Use case diagram (Diagramma dei casi d’uso):elenca i casi d’uso del sistema e le loro relazioni

� Class diagram (Diagramma delle classi):descrive la struttura dati degli oggetti, del sistema e le loro relazioni

� Object diagram (Diagramma degli oggetti):insieme di oggetti della realtà d’interesse e loro relazioni

� Interaction diagram (Diagramma d’interazione): interazione tra oggetti

� State e activity diagram (Diagramma di stato e di attività): Stato di un oggetto e sequenze eventi-azioni-transazioni

� Deployment diagram (Diagramma di distribuzione):descrive la struttura del sistema HW e l’allocazione dei moduli SW

� Component diagram (Diagramma dei componenti): Descrive l’architettura fisica del sistema

� Sequence diagram (Diagramma sequenziale)

� Collaboration diagram (Diagramma di collaborazione)

Statici

Dinamici

Imple

m.


Use case diagram: Elementi Fondamentali

Mostra:• le modalità di utilizzo del sistema (casi d’uso)• gli utilizzatori e coloro che interagiscono con il

sistema (attori)• le relazioni tra attori e casi d’uso

Un caso dcaso d ’’usouso• rappresenta un possibile “modo” di utilizzo del sistema• descrive l’interazione tra attori e sistema, non la “logica

interna” della funzioneuna funzionalità dal punto di vista di chi la utiliz za


Use case diagram: Come si producono ? (01)

� Gli use case possono essere ricavati dalle interviste con gli utenti.

Si identificano:

� Gli obiettivi: ciò che il sistema dovrebbe fare secondo gli utenti

� Le interazioni: cosa vorrebbero (o potrebbero) fare i diversi utenti

� Gli use case di alto livello sono generici

� I dettagli si aggiungono raffinando le funzionalità del sistema


Use case diagram: Come si producono ? (02)

� La loro definizione è iterativa

� Si inizia identificando i comportamenti più semplici

� Si continua descrivendo i comportamenti più complessi

Quando ci si può fermare ?

� Un buon livello di dettaglio facilità tutte le attività successive

� Se ci si focalizza troppo sui dettagli questi:

� Potrebberò introdurre troppo presto scelte progettuali

� Non consentirebbero una visione d’insieme

� Complicherebbero la descrizione


Use case diagram: Elementi Fondamentali

Casi : un caso è un’unità funzionale parte del sistematipiche interazioni fra utente e sistemaesprimono le procedure esistenti nel dominio intermini di scenari operativi

Attore : è qualcuno (utente) o qualcosa (sistemi esterni -hardware) che:

� Scambia informazioni con il sistema� Fornisce input o riceve output dal sistema� Responsabile dell’istanziazione di 1 o più Use

Case� Non fa parte del sistema

SemanticaNotazione grafica


Use case diagram: Esempio

acquistare articoli

log in cassierecliente

rimborsare articoli venduti caso d'uso: un "modo" di utilizzare il sistema

attore: un utilizzatore del sistema


Use case diagram: Relazioni Fondamentali

extends : definisce una funzionalità per estensione di una funzionalità già esistente (descrive una variazione sul normale comportamento)

Uses (o include) : uso di una certa funzionalità (utile quando funzionalità simili sono presenti in più contesti o Use Case, utile per evitare ripetizioni)

Interazione : indicano relazioni tra attori e casi

SemanticaNotazione grafica


Use case diagram: Extends

Extends: indica che uno use case è simile a un altro ma è piùspecifico� Pertanto gli attori hanno una relazione verso lo use

case che viene esteso

� Si assume che un dato attore sia legato sia al caso base che a tutte le estensioni

Esempio: Ordine di un prodotto e ordine via internet

cliente Ordine Ordine via Internet

Nota: uno use case che estende un altro sono allo stesso livello, ma offrono funzionalità diverse (uno non è più generico dell’altro)


Use case diagram: Uses

Uses (o include ): fattorizza attività ricorrenti e condivise. Quindi uno use case ne utilizza un altro (magari comune a più use case); è una dipendenza (stereotipo predefinito)

Ordine

Dati cliente Disp. prodotto

Mod. pagamentoGestione credito

Esempio: Ordine di un prodotto


Use case diagram: Alcuni suggerimenti

� Identificare sostantivi e verbi

� Distinguere tra sostantivi che indicano componenti interni ed esterni

� Selezionare i verbi che indicano azioni principali da parte del sistema


Use case diagram : Utilizzo

Un possibile metodo per definire gli use case

� Modellazione ad alto livello del comportamento di un elemento: intero sistema o sottosistema

� Strumento di comunicazione fra analisti, utenti, sviluppatori

� Base per il test

� Individuare gli attori

� Organizzare gli attori (casi particolari: generalizzazioni)

� Per ogni attore individuare le principali iterazioni con il sistema (casi base e alternative ed eccezioni)

� Organizzare gli use case


Use case diagram: Esercizio-Sistema registrazione corsi (01)

All’inizio di ogni semestre, l’ufficio amministrativo dell’università dovrà fornire agli studenti la lista dei corsi disponibili, attraverso un sistema di registrazione on-line. Il sistema dovrà fornire tutte le informazioni relative al corso: professore, dipartimento eventuali propedeuticità.Il nuovo sistema dovrà consentire agli studenti di selezionare quattro corsi fra quelli disponibili. In aggiunta ogni studente indicherà due alternative. Nessun corso potrà avere più di 10 studenti. Corsi con meno di 3 studenti verranno cancellati in modo automatico dal sistema. In caso di richiesta adeguata si potrebbero anche fare più corsi per la stessa materia.


Use case diagram: Esercizio-Sistema registrazione corsi (02)

I professori dovranno essere in grado di accedere al sistema on-line per indicare i corsi in cui insegneranno e anche per vedere gli studenti iscritti ai loro corsi.Il processo di registrazione dura 3 giorni. Il primo giorno èriservato agli studenti del primo anno. Il secondo giorno èriservato agli altri studenti. Durante il terzo giorno si risolvono eventuali conflitti.Finito il processo di registrazione, le informazioni relative ad un studente sono inviate all’ufficio contabile per determinare le tasse da pagare.Durante il semestre gli studenti devono essere in grado di accedere al sistema per aggiungere o togliere corsi


Use case diagram: Possibile soluzione

Cambiamento Organizzazione Corso

Richiesta Iscritti

Professore

Selezione Corso

Gestione Informazioni Professori

Gestione Informazioni Studenti

Archivista

Gestione Curriculum

Richiesta Catalogo Corsi

Cambiamento Agenda Corsi

Studente

Registrazione CorsiUfficio Contabile


Use case diagram: Scenari

Uno scenario è un’istanza di uno use case:

� Definisce gli eventi in un caso particolare di esecuzione del programma

� Uno scenario è solitamente definito in linguaggio naturale. Si rispetta l’ordine temporale

� Gli eventi devono essere semplici e autoesplicativi (non devono includere alternative complesse)

NOTA: Servono tanti scenari quanti sono quelli necessari per capire il sistema


Use case diagram: Scenari

�Scenario principale (più possibile) � Tutto funziona correttamente

Bisogna considerare diversi livelli d’astrazione

�Scenari secondari (pochi e significativi) � Eccezioni (eventuali problemi o malfunzionamenti)

Ogni use case potrebbe avere un insieme di scenari:

Gli scenari sono descritti per mezzo dei diagrammi di interazione (di sequenza e di collaborazione)


Use case diagram: Un esempio di scenario

Registrazione ai corsi:Gianluca sceglie i corsi: informatica, fisica, analisi e disegnoCome corsi alternativi sceglie: fotografia e giornalismoI corsi scelti sono immessi nel sistema di registrazioneLo studente viene aggiunto ai primi 3 corsi principaliIl quarto corso non è disponibileSE la prima alternativa è disponibile ALLORA

lo studente viene aggiunto al corsoALTRIMENTI SE la seconda alternativa è disponibile ALLORA

lo studente viene aggiunto al corsoALTRIMENTI si notifica allo studente che non è iscritto ad

un numero sufficiente di corsiSE NON fallisce ALLORA

Si crea la cartella corsi dello studenteSi mandano le informazioni all’ufficio contabile


Use case diagram: Documentazione

Per ogni caso d’uso:

Eccezioni

…..Scenari

…..Post-condizioni

Non identificatePre-condizioni

Ufficio contabile, Studente registratoAttori

Quando le iscrizioni di uno studente sono state accettate si inviano le informazioni all’ufficio contabile

Descrizione

Rossi e BianchiAutori

Computo tasseTitolo


Activity Diagrams

Permette di modellare processi paralleli e la loro sincronizzazione

Si descrive il comportamento attraverso un’insieme di attività

Modellazione di workflow:

� Attività a livello abbastanza alto (il flusso di oggetti può essere importante; le corsie possono essere utili)

� A livello più dettagliato (branch, fork, join sono importanti)

Modellazione di operazioni:


Activity Diagrams: Elementi

Stati : i nodi del diagramma

� Stati di azioni (action state): atomici� Stati di attività: decomponibili

� Stati particolari: inizio e fine

Transizioni : archi che descrivono il passaggio da una attivitàad un'altra

� Semplici

� Diramazioni (branching)

� Stati concorrenza: fork e join

Corsie (swimlanes): descrivono la "competenza" per lo svolgimento delle attività (in termini di soggetti del mondo reale) Si delimita da altri gruppi con una linea verticale.

Flusso di oggetti : le attività si possono inviare oggetti, nel cedere il controllo


Activity Diagrams: Elementi principali

[ espress. Bool. ]

etichetta

Rilascioautorizzazione

*

Transizione

Barra di sincronizzazione(Join, fork)

Condizioneguardiano,trigger

Stato di azione(Attività)

Pseudo stato iniziale

Pseudo stato finale

Decisione

Iterazione

� Possono essere associati all’implementazione di un’operazione, ad un caso d’uso o una classe.

� Servono ad enfatizzare i flussi dell’elaborazione interna.

� Sono utili nei casi in cui la fine delle attività interne è considerata un evento oppure è accompagnata dall’emissione di uno o più eventi.

I diagrammi di attività sono un’alternativa agli STD in cui i nodi/stati sono attività/azioni che rappresentano l’esecuzione di operazioni.Quando gli eventi sono asincroni, sono preferibili i diagrammi STD.


Activity Diagrams: Esempio

Cliente Vendite Magazzino

Paga

Spediscimerce

Riceviordine Completa

ordine

Ricevimerci

Richiediservizio

attività

Barra disincronizzazione

corsie


Activity Diagrams: Fork e Join

Fork = Rappresenta un flusso di controllo spaccato in più flussi di controllo concorrenti. Una fork ha un flusso in ingresso e più flussi in uscita. Per ciascun flusso in uscita, le attivitàassociate continuano in parallelo con le attività dei flussi paralleli.

fork

join

Le attività che sono in flussi paralleli possono comunicare tra loro inviando dei segnali

Join = Rappresenta la sincronizzazione di due o più flussi di controllo concorrenti. All’arrivo nella join, un flusso deve aspettare finché tutti i flussi sono arrivati. Tra una fork e la joincorrispondente ci deve essere un bilanciamento: N flussi escono dalla fork, N flussi debbono entrare nella join.


Activity Diagrams: Esempio

Rilasciare barattolo Cola

Trovata la bevanda

Mettere il caffènel filtro

Aggiungere acqua Rilasciare il bichiere

Mettere il filtro nella macchina

Attivare la macchina

Fare bollire il caffe Consumare la bevanda

[ manca Cola ][ manca il caffè ]

[ trovato il caffè ]

[ le luci spente ]

decisione


Activity Diagrams: Esercizio

Descrivere il processo con un activity diagram

La ricezione di un ordinativo in un’azienda comporta il controllo della forma di pagamento prevista ed il controllo della disponibilità delle merci ordinate. La mancata autorizzazione al pagamento comporta la cancellazione dell’ordine. Ogni merce, se disponibile, viene assegnata all’ordine. Quando tutte le merci richieste sono state selezionate l’ordine può essere evaso e si procede a riordinare le merci la cui disponibilità non è più sufficiente.


Activity Diagrams: Possibile soluzione

RiceviOrdine

ControllaPagamento

ControllaDisponibilità

CancellaOrdine

Assegna a Ordine

RiordinaMerce

EvadiOrdine

* Per ogni linea dell’ordinefallimento

successo

tutte le merci disponibili


Class Diagrams

• E’ il caposaldo dell’object oriented e definiscono la visione statica del sistema

• Rappresenta le classi di oggetti del sistema con i loro attributi e operazioni

• Può essere utilizzato a diversi livelli di dettaglio (in analisi e in disegno)

• Mostra le relazioni tra le classi (associazioni, aggregazioni e gerarchie di specializzazione/generalizzazione)


Class Diagrams

Descrizione statica del sistema:

Classi� Nomi

� Attributi (lo stato)

� Metodi (il comportamento)

Relazioni tra classi� Associazioni (uso)

� Generalizzazione (ereditarietà)

� Aggregazione (contenimento)


Class Diagrams: Classi

Una classe è un insieme di entità del sistema o dell’ambiente, con caratteristiche comuni. Una classe è composta da tre parti:

Nome

Nome e metodi

Nome e attributi

� nome

� attributi

� metodi

Professore

Nome

Cognome

Professore

Professore

Nome

Cognome

Create()Delete()

Professore

Create()Delete()


Class Diagrams: Classi come individuarle?

� Evidenziare i nomi (oggetti) nella specifica del problema

� Considerare gli use case e gli scenari

� Si raggruppano gli oggetti in classi

� Si definiscono gli use case

� Si specificano alcuni use case in scenari

� Si identificano gli oggetti propri di ogni scenario

Quindi:

� Guardare � Considerare i risultati precedenti e altri sistemi, prototipi, specifiche

� Cercare � Strutture, cose ed eventi, ruoli, unitàorganizzative, procedure operative

� Considerare � molteplicità di attributi e istanze, funzioni sempre presenti, requisiti del dominio


Class Diagrams: Esercizio

Identificare gli oggetti per il sistema di registrazione dei corsi a partire da:

use case (slide 26, 27)scenario (slide 31)


Class Diagrams: Possibile soluzione

Gianluca

Corso

Informatica

Fisica

Analisi

Disegno

Corso alternativo

Fotografia

Giornalismo

Sistema di registrazione

Studente

Corso principale

Alternativa

Notifica

Cartella studente

Informazioni

Selezione

Ufficio contabile

Come raggruppare ?


Class Diagrams: Come raggruppare

� Esaminando gli oggetti identificati negli scenari, alcuni oggetti possono essere raggruppati

� Tutti i corsi specifici appartengono alla classe Corso

� La lista può crescere considerando i diversi scenari

� Si individua anche la classe Studente, Professore,…..



Definire il modello iniziale delle classi per il sistema “Registrazione corsi” slide 26, 27 a partire dalla lista di nomi identificati


Class Diagrams: Soluzione modello iniziale delle classi

Catalogo Corsi

Professore

Elenco Iscritti

Corso

Informazioni Contabili

Studente

Cartella Studente


Class Diagrams: Attributi come individuarli ? (01)

� Un attributo è una caratteristica della classe

� Gli attributi hanno una loro identità non la si deve aggiungere

� Ogni attributo deve essere definito in modo preciso

� Gli attributi dipendono dal dominio

Persona in ambito medico� nome, cognome, peso, altezza

ESEMPIO:

Persona in ambito bancario� nome, cognome, codiceFiscale, numeroConto

Per studente attributi corretti� nome, cognome

Per studente attributi NON corretti� CorsiScelti


Class Diagrams: Attributi come individuarli ? (02)

� Direttamente nel testo della specifica

� Durante la definizione delle classi stesse

� Conoscenza del dominio applicativo


Class Diagrams: Attributi derivati

Un attributo derivato è un attributo il cui valore viene calcolato in base ai valori di altri attributi (quindi calcolato e non memorizzato)

ESEMPIO:

� età, area, perimetro

Si usa quando non si vuole ricalcolare tutti i valori per quell’attributo nei vari oggetti


Class Diagrams: Metodi

� Un metodo è una trasformazione applicabile a una istanza di una classe

� Tutti e solo i metodi rilevanti per il dominio applicativo

In ambito medico� EsegueEsame, PrendeMedicina, …

ESEMPIO:

In ambito bancario� ApreContoCorrente, EffettuaPrelievo, …


Class Diagrams: Relazioni

� La molteplicità definisce il numero di istanze che prendono parte alla relazione

� Una relazione definisce un canale di comunicazione bidirezionale fra due classi

� Alcune relazioni sono: associazioni e aggregazioni

� Tutti i sistemi sono composti da oggetti che collaborano per realizzare le funzionalità richieste


Class Diagrams: Relazioni durante l’analisi ed il progetto

� Le connessioni sono date dalla (insite nella) natura stessa del problema

� Durante l’analisi si stabiliscono relazioni (associazioni o aggregazioni) fra classi

� Si deve pensare alle possibili molteplicità per esplicitare assunzioni implicite

Durante il progetto:

� Le molteplicità vengono modificate e raffinate

� Le associazioni stesse vengono raffinate


Class Diagrams: Associazioni

Corso CartellaStudenteappare

� indica una relazione tra classi (ad es. una persona che lavora per una azienda)

� deve avere un nome, solitamente un verbo (un etichetta al centro della linea che definisce l’associazione)

Un’associazione:


Class Diagrams: Molteplicità

Corso Studente3 .. 100..*

� Se l’associazione è obbligatoria oppure no

La molteplicità indica:

� Il numero minimo e massimo di oggetti che possono essere relazionati ad un altro oggetto

segue

ESEMPIO:


Class Diagrams: Molteplicità

1..1Esattamente 1

* 0 o più

0..10 o uno

m..n, 4..7, 9 entro gli estremi specificati


Class Diagrams: Aggregazioni

Corso Curriculum1..11..*

Le aggregazioni sono una forma particolare di associazione. Una parte è in relazione con un oggetto (part-of)

A B Indica che A e’ parte di B

ESEMPIO:


Class Diagrams: Associazione o aggregazione ?

Curriculum1..*

Corso1..1

Studente3..10

� Aggregazione se due oggetti sono “uniti” da una relazione part-of (ad es: auto con motore e ruote)

� Associazione se due oggetti sono solitamente considerati indipendenti, anche se spesso “collegati”

0..* segue

ESEMPIO:


Class Diagrams: Associazioni riflessive

AggregazionePropedeuticità

0..*0..*

La Un’associazione è riflessiva se coinvolge oggetti della stessa classe

� Indicano oggetti multipli della stessa classe che collaborano in qualche modo

Corso Parte


Class Diagrams: Attributi delle associazioni

3..10Studente Corso

Frequenza

Profitto

Percentuale

0..*segue

� È permesso una sola classe attributo per associazione

� La classe attributo può avere proprietà specifiche

� L’attributo si mette all’interno dell’icona di una classe e si collega l’icona all’associazione (si parla di classe associativa)

ESEMPIO:

Solo un’istanza della classe associativa tra ogni coppia di oggetti associati


Class Diagrams: Esempio

*Persona Azienda

Impiego

Periodo

0..1lavora

*Persona Azienda

Impiego

Periodo

0..1lavora

1 1

0..* *

Si permette ad una persona di avere più di un impiego nella stessa azienda

Si permette ad una persona di avere al massimo un impiego nella stessa azienda

Da classe associativa a classe quando ?


Class Diagrams: Ereditarietà (� Generalizzazione)

� Esplicità eventuali comportamenti comuni

� Richiede che si debba:

� Aggiungere nuove proprietà alle classi

� Ridefinire/modificare metodi esistenti

� Definisce il concetto di generalizzazione

� La classe figlie ereditano attributi e metodi dalla classe ‘padre’ e possono avere propri attributi e metodi

Persona

Studente Docente

Padre general.

Figli general.


Class Diagrams: Esempio

Amministratore

Cassiere

Negozio

nome

indirizzo

Prodotto

POST

*

1

*

1

avviato da

11 11

utilizzato da

1..*1

1..*1

Riga vendita0..*

1

0..*

1

descrive

Vendita

data

ora

crea_vendita()

11*

1..* 11..* 1

ha

Pagamento

importo

11

1riferito a

Pag. Contanti

Pag. Carta Credito

Aggregazione

Associazione

Specializzazione/ Generalizzazione



Definire le relazioni per il modello delle classi per il sistema di registrazione corsi (slide 26, 27)

Catalogo Corsi

Professore

Elenco Iscritti

Corso

Informazioni Contabili

Studente

Cartella Studente


Class Diagrams: Una soluzione (inizio)

3..10

Precedenze

0..*0..*

1..1

1..*1..1

1..1

1..1

1..10..*

1..*

1..*

Catalogo Corsi Cartella Studente

Studente

Professore

Elenco Iscritti

Corso


Interaction Diagrams

� Sequence Diagram

� Oggetti

Descrivono il comportamento dinamico del sistema.

Specifica del modo in cui vengono inviati messaggi tra diverse istanze per eseguire un compito specifico

Ad uno use case si possono associare diversi interaction diagrams

Comprendono

� Collaboration Diagram

Elementi fondamentali

� Scambio messaggi� Sequenza di invocazione dei messaggi


Interaction Diagrams: Messaggi e interazione

Interazione : specifica del modo in cui vengono inviati messaggi tra diverse istanze per eseguire un compito specifico.

Messaggio : specifica di una comunicazione tra istanze, che trasmette informazione nell'aspettativa che ne consegua attività�evento

� Call : invoca un'operazione su oggetto (anche se stesso)

Tipi di messaggi:

� Return : restituisce un valore al chiamante

� Send : invia un "segnale" ad un oggetto

� Create : crea un oggetto

� Destroy : distrugge un oggetto (anche se stesso)


Interaction Diagrams: Notazione per i messaggi e interazione

Call:

Return:

Send:

Create:

Destroy:

Interazione sincrona:

risposta:

Interazione asincrona:

Interazione non specificata(di solito asincrona)


Sequence diagram

� E’ utilizzato per definire la logica di uno scenario (specifica sequenza di eventi) di un caso d’uso (in analisi e poi ad un maggior livello di dettaglio in disegno)

� E’ uno dei principali input per l’implementazione dello scenario

� Mostra gli oggetti coinvolti specificando la sequenza temporaledei messaggi che gli oggetti si scambiano

� E’ un diagramma di interazione ed evidenzia come un caso d’uso è realizzato tramite la collaborazione di un insieme di oggetti


Sequence diagram: elementi principali

Oggetto “Linea della vita”dell’oggetto

Messaggio- call- return- send- create- destroy

{b-a


Sequence diagram: Esempio

Scegli corso

Inoltra selezioneCorso disponibile?

Aggiungi UtenteRegistrazione OK

Utente Selezione corso Corso

Oggetti

TempoUnified Modeling Language Università degli Studi Roma Tre - Gianluca Di Tomassi 74

Sequence diagram: Quando e perché utilizzarli ?

� Si possono specificare nodi decisionali o iterazioni

� Aggiungere se necessario vincoli di spazio e tempo o pre o post condizioni ai msg

� Utilizzare il focus of control per visualizzare il nesting dei messaggi o i tempi in cui avviene la computazione

� Identificare gli oggetti coinvolti e posizionarli per importanza

� Individuare il contesto dell’interazione (sistema, sottosistema,…)

� Usati per modellare un flusso di controllo per ordine temporale


Sequence diagram: Esercizio

Scrivere il sequence diagram corrispondente ad un prestito in una biblioteca

Utente Controllo tessera Ricerca volume


Sequence diagram: Una soluzione

Utente Controllo tessera Ricerca volume

Invia richiesta

Prestito OK

Ricerca volume

Volume disponibile

Tessera OK


Collaboration diagram: elementi principali

Classe:Oggetto

Oggettopartecipante

Link

Self-link

2: etichetta Messaggio

� E’ un diagramma di interazione e rappresenta un insieme di oggetti che collaborano per realizzare il comportamento di uno scenario di un caso d’uso

� Può essere utilizzato in fasi diverse (analisi, disegno di dettaglio)

� A differenza del diagramma di sequenza, mostra i link (legami) tra gli oggetti che si scambiano messaggi, mentre la sequenza di tali messaggi è meno evidente

� Non prevedono l’uso del concetto di tempo


Collaboration diagram: Esempio

Si vuole realizzare un’applicazione per la condivisione di file. Gli utenti devono autenticarsi con il server fornendo una usernamee password. Una volta autenticati possono effettuare ricerche per cercare file. Trovato il file desiderato l’utente puo’ effettuarne il download

:Utente

:Server

1: Autenticazione

2: Ricerca 3: Risultato

4: Dowload

Realizzare il corrispondente sequence diagram

Utente Server

Ricerca

Risultato

Autenticazione

Download


Collaboration diagram: Esercizio

Riprendere l’esercizio sul “Sistema registrazione corsi”(slide 26, 27) e realizzare il relativo Collaboration diagram


Collaboration diagram: Soluzione

:Corso

:SelezioneCorso

:InformazioniContabili

:CartellaStudente

:Studente

1: Seleziona 4 corsi

2: Seleziona informatica3: Seleziona analisi4: Seleziona fisica5: Seleziona disegno

6: Seleziona 2 corsi alt.

7: Seleziona fotografia8: Seleziona giornalismo9: Sottometti corsi

10: Corso disponibile11: Aggiungi Studente

12: Crea cartella

13: Crea info contabili


Riassumendo ...

� Uno scenario può essere rappresentato per mezzo di un interaction diagram, Sequence diagram e collaboration diagramche quindi rappresentano le stesse informazioni

� Cambia la forma concreta

� Si pone l’enfasi su aspetti leggermente diversi

� I collaboration facilitano il raggruppamento delle classi in packages e sono più evidenti i legami fra gli oggetti

� Commenti testuali possono fornire ulteriori dettagli al modello definito


State Transition Diagrams

� E’ normalmente utilizzato per modellare il ciclo di vita degli oggetti di una singola classe

� Mostra gli eventi che causano la transizione da uno stato all’altro, le azioni eseguite a fronte di un determinato evento

� Quando un oggetto si trova in un certo stato può essere interessato da determinati eventi (e non da altri)

� è opportuno utilizzarlo solo per le classi che presentano un ciclo di vita complesso e segnato da una successione ben definita di eventi

� In UML Statechart


State Transition Diagrams: elementi principali

TransizioneCondizione/azione

c/a

Auto transizione

Condizioneguardiano

statoStato dell’oggetto

Pseudo stato inizialePseudo stato finale

[n


State Transition Diagrams: Esercizio

Progettare il diagramma degli stati (Statechart) per la classe selezione corso“Il sistema dovrà consentire agli studenti di selezionare quattro corsi fra quelli disponibili. In aggiunta ogni studente indicherà due alternative”


State Transition Diagrams: Possibile Soluzione

CreazioneSelezione

corsi

Selezione corsi extra

Sospeso

Salva

Sottometti

corsi < 2

corsi < 4sospendi

ricomincia

quit

corsi = 2


Package Diagrams

� Permettono la partizione del sistema in sottosistemi (utili per dominare la complessità del dominio) costituiti da elementi omogenei di:

� Ogni elemento appartiene ad un solo package

� natura logica (classi, casi d’uso, …)

� natura fisica (moduli, tabelle, …)

� altra natura (processori, risorse di rete, …)

� Un package può referenziare elementi appartenenti ad altri package


Package diagram: elementi principali

XX

global

(from XX) (from XX)

Pacchetto Relazione di dipendenza Relazione di generalizzazione

Streotipizzare Relazione “possiede”

Ai pacchetti si applicano cinque stereotipi standard:facade - specifica un pacchetto che è solo una vista su un altro pacchettoframework - specifica un pacchetto che contiene patternsstub - specifica un pacchetto che serve come un proxy per gli elementi esportati di un altro pacchettosubsystem - specifica un pacchetto che rappresenta una parte indipendente del sistema da modellaresystem - specifica un pacchetto che rappresenta l’intero sistema da modellare.


Package Diagrams: Esempio

Servizi di base

Oracle Java VirtualMachine

Java.applet

Negozio

1..*Negozio Manager1*1

Package


Deployement Diagrams

� Sono propri della fase di implementazione

� Raggruppamento del codice in moduli

� Evidenziano le dipendenze tra i moduli


Component Diagrams

� Evidenzia l'organizzazione e le dipendenze tra i componenti software

� I componenti (come a livello logico i casi d’uso o le classi) possono essere raggruppati in package

� Un componente è una qualunque porzione fisica riutilizzabile con un’identità e un’interfaccia (dichiarazione di servizi offerti) ben definite

� Un componente può essere costituito dall’aggregazione di altri componenti

� I component e deployment diagrams sono simili ai diagrammi delle classi, eccetto che invece di contenere classi contengono componenti e nodi rispettivamente


Component Diagrams: Notazione

� Si esplicitano le dipendenze tra moduli

NewPackageSpec

NewComponent

NewPackage

Specifica di un nuovo Package

Componente

Package


Component Diagrams: Esempio

Vendita.exe

Vendita.java

Prodotto.java

POST.java

Java.awt

Componente

Dipendenza


UML: Considerazioni

� UML rappresenta un’evoluzione dei modelli preesistenti, più che una rivoluzione

� UML è adatto a esprimere modelli di varia tipologia, creati per obiettivi diversi

� UML può descrivere un sistema software a diversi livelli di astrazione, dal piano più svincolato dalle caratteristiche tecnologiche fino all’allocazione dei componenti software nei diversi processori in un’architettura distribuita

� UML è sufficientemente complesso per rispondere a tutte le necessità di modellazione, ma è opportuno “ritagliarlo” in base alle specifiche esigenze dei progettisti e dei progetti, utilizzando solo ciò che serve nello specifico contesto


Sommario













Metodologie per UML

� Per usare con successo UML occorre adottare una metodologia

� Utilizzare una metodologia aumenta la possibilità di riuso

� Le caratteristiche di una metodologia

� Descrive cosa fare, come, quando e perchè

� Comporta un certo numero di attività da portare a termine in un certo ordine

� Permette la realizzazione di una documentazione di progetto esauriente


Metodologie per UML: Requisiti (01)

� Guidata dai casi d’uso

� I casi d’uso catturano i requisiti funzionali del sistema, e influenzano tutte le fasi

� L’architettura di massima deve essere stabilita prima possibile

� Centrata sull’architettura

� L’architettura definisce le parti del sistema, le loro relazioni e interazioni, i meccanismi di comunicazione


Metodologie per UML: Requisiti (02)

� Il sistema non viene rilasciato “tutto insieme” al termine del progetto, ma viene sviluppato e rilasciato (esternamente o internamente) in più parti

� Incrementale

� Un incremento del sistema (versione) è costituito da una o più iterazioni

� Lo sviluppo di ciascun diagramma comprende una sequenza di passi, ognuno aggiunge informazioni o dettagli

� Iterativa

� Ciascuna iterazione viene valutata ed eventualmente prototipata

� Conviene affrontare i problemi più difficili durante le prime iterazioni


Sviluppo tradizionale

� Produce diagrammi dei casi d’uso, alcuni semplici diagrammi delle classi, eventualmente qualche diagramma di attività

� Analisi dei requisiti: genera un accordo tra il cliente e il fornitore del sistema su aspetti funzionali, prestazionali, di affidabilità; ambienti operativi; integrazione con l’esistente;

� Produce diagrammi delle classi, di interazione, di stato e di attività

� Analisi: genera un modello del dominio applicativo, libero da dettagli tecnici e implementativi

� produce diagrammi dei componenti e di distribuzione

� Progettazione: genera una estensione tecnica del modello di analisi,che specifica dettagli tecnici e implementativi

� Implementazione

� Testing


RUP ovvero Rational Unified Process

� E’ la versione commerciale, prodotta da Rational Software, di Unified Process, il processo definito da Booch, Rumbaugh, Jacobson (gli autori di UML)

� E’ un framework di processo, da adattare alle diverse tipologie di progetto

� E’ utilizzato in contesti di business estremamente competitivi, e in ambiti applicativi eterogenei

� Risponde agli obiettivi primari di time to market, controllo del rischio e visibilità degli stati di avanzamento


RUP: Principali caratteristiche (01)

� Guidato dai casi d’uso. Essi costituiscono la base per:� La definizione e negoziazione dei requisiti, e la loro

validazione da parte del committente

� La progettazione dell’architettura e dei componenti

� La definizione dei test di accettazione

� La pianificazione dei rilasci (in un’ottica incrementale) e quindi del progetto

� Iterativo

� Il progetto si articola in una serie di iterazioni (sequenze di attività), che hanno lo scopo di ridurre progressivamente i rischi di fallimento, a partire da quelli principali (es. incomprensioni sui requisiti, incertezze sull’architettura)

� in ogni iterazione si ripetono, in misura e percentuali diverse, le medesime tipologie di attività (es. analisi dei requisiti, design, implementazione, test)



� Centrato sull’architettura

� La definizione dell’architettura applicativa e tecnologica costituisce il fondamento tecnico dell’applicazione e del progetto

� Il consolidamento dell’architettura avviene solo quando si ècerti della sua fattibilità tecnica.

� Fino a quando l’architettura non è consolidata, non esistono elementi sufficienti per determinare (con precisione sufficiente alla definizione di un contratto) tempi, costi e rischi dell’intervento progettuale

� Incrementale� La realizzazione (ed eventualmente il rilascio) dell’applicazione

avviene in modo progressivo

� La pianificazione è guidata dai casi d’uso e dalle prioritàarchitetturali (es. precedenza ai componenti infrastrutturali)



� Basato sui modelli

� RUP enfatizza lo sviluppo e il mantenimento di modelli piuttosto che la produzione di montagne di documentazione cartacea

� Orientato agli oggetti

� Gran parte dei modelli usati sono basati sui concetti di classe,oggetto, associazione

� Orientato al controllo qualità e alla gestione dei rischi

� Sono parte inscindibile di ciascuna fase

� Configurabile

� Nessun processo è adatto per tutte le situazioni; la configurabilità si raggiunge attraverso la selezione delle viste e dei diagrammi utili e attraverso la gestione delle iterazioni


RUP: Un modello

� Un ruolo definisce il comportamento e le responsabilità di un individuo o un gruppo

� Il comportamento è espresso in termini di attività

� Le responsabilità sono espresso in termini di elaborati da produrre e gestire


RUP: Elaborati

� Set di gestione� elaborati di pianificazione (software development plan,…)

� elaborati operazionali (Sal, descrizione versione, …)

� Set dei requisiti� documento di visione � modello dei casi d’uso

� modello di business

� Set di progettazione� documento di design � modello architetturale

� modello di test� Set di implementazione

� codice sorgente ed eseguibili � file di dati� Set di rilascio agli utenti

� script di installazione � documentazione e materiale formativo


RUP: Le fasi

� Inception: definisce gli obiettivi del progetto, ne investiga la fattibilità,ne stima i costi, il potenziale di mercato e i rischi, analizza i prodotti concorrenti

� Elaboration: pianifica il progetto e ne definisce le caratteristiche funzionali, strutturali e architetturali

� Construction: sviluppa il prodotto attraverso una serie di iterazioni, effettua il testing, prepara la documentazione

� Transition: consegna il sistema agli utenti finali (include marketing, installazione, configurazione, formazione, supporto, mantenimento)


RUP: Output fasi

� Inception: Documenti fattibilità

� Elaboration: SRS (Specifica dei Requisiti Software) e Architettura consolidata e verificata

� Construction: Versione sistema in pre-produzione (Beta)

� Transition: Versione sistema in produzione


RUP: Fasi e attività (01)


RUP: Fasi e attività (02)

� Le fasi sono sequenziali, e corrispondono a milestone significativi per Committenti, Utenti, Management

� Le tipologie di attività non sono rigidamente sequenziali, e vengono svolte dal progetto in ogni iterazione

� Il numero delle iterazioni dipende dalle scelte del Project Manager e dai rischi del progetto


RUP: Caratteristiche del processo (01)

Iterativo e

incrementale


RUP: Caratteristiche del processo (02)

� I problemi gravi sono evidenziati all’inizio del ciclo di vita,quando il costo per la correzione è inferiore

� Viene incoraggiato lo scambio di informazioni con gli utenti

� Il team di sviluppo si focalizza da subito sugli aspetti più critici del progetto

� Il test eseguito a ogni iterazione permette una valutazione oggettiva dello stato di avanzamento del progetto

� Le incoerenze tra requisiti e progetto vengono identificate molto presto

� Il carico di lavoro del team è suddiviso nel tempo in modo piùuniforme

� Il team può utilizzare le competenze acquisite nel corso del progetto per migliorare il processo di sviluppo


RUP: Punti di forza

� le attività da effettuare

� i documenti in input e in output alle diverse attività

� E’ un processo ampiamente utilizzato, da anni, in contesti eterogenei quindi è sperimentato e consolidato

� Comprende una massa notevole di linee guida e template: fornisce indicazioni concrete su come operare in un approccio diprogettazione Object Oriented

� Definisce in modo approfondito:

� i ruoli coinvolti nel processo di sviluppo


RUP: Limiti

� È un processo il cui ambito è esclusivamente il singolo progetto

� è un framework di processo generico, non mirato ad alcuna tipologia specifica di applicazioni

� Ha origine in una cultura di sviluppo mirata alla realizzazione di prodotti commerciali, e quindi non prevede:

� la gestione dei rapporti contrattuali con fornitori

� l’acquisizione (ed eventuale personalizzazione) di package commerciali

� La gestione dei rapporti contrattuali tra committenti “business”e sviluppatori


RUP: Cosa fare per utilizzarlo ?

� deve essere adattato, senza stravolgimenti, alle esigenze e allecaratteristiche dell’organizzazione tenendo conto di:

� L’adattamento deve avvenire in modo progressivo, e costituisce a sua volta un progetto, iterativo e incrementale

� Cultura dell’organizzazione in cui viene calato

� Struttura organizzativa, ruoli, responsabilità

� Tipologia di sistemi da realizzare (automazione, gestionale,B2C)

� Modalità di rapporto con i committenti

� Differenze tra progetti di nuovo sviluppo ed evoluzioni


RUP: Costi

� Costi di impatto culturale

� Costi tecnologici

� Costi a Regime

� Costi di impatto organizzativo


RUP: Costi di impatto organizzativo

� Può portare ad una ridefinizione dei ruoli, rispetto a quelli in essere

� Può portare ad una ridefinizione delle modalità di comunicazione e di rapporto con Committenti e Utilizzatori

� Il processo può risultare molto diverso dagli “stili” di lavoro in essere nell’organizzazione che lo adotta

� Può portare ad una ridefinizione delle modalità di comunicazione e di rapporto con eventuali Fornitori


RUP: Costi di impatto culturale

� Una diversa percezione del proprio ruolo in rapporto alla committenza ed agli utilizzatori

� Una ridefinizione di alcuni concetti cardine dello sviluppo (analisi, requisiti, test, manutenzione)

� un cambiamento significativo del modo di lavorare (procedure,responsabilità, tecniche)

� La necessità di apprendere nuove tecniche (es. approccio Object Oriented alla progettazione dei sistemi, gestione dei requisiti)

Può portare:


RUP: Costi tecnologici

� La disponibilità degli strumenti non è comunque un prerequisito indispensabile per l’efficacia del processo

� L’utilizzo del nuovo processo può essere agevolato dall’acquisizione di strumenti specifici disponibili sul mercato per le attività primarie di sviluppo, tra cui:

� gestione dei requisiti e delle richieste di cambiamento

� analisi e design

� generazione di codice

� testing


RUP: Costi a regime

� Deve essere adattato ad ogni specifico progetto, per tenere conto delle specifiche caratteristiche e limitazioni

� Il processo deve essere gestito in un’ottica di continuo miglioramento e adattamento all’evolversi delle esigenze aziendali


XP ovvero eXtreme Programming

XP è un rappresentante delle cosiddette metodologie agili

Una metodologia agile è una metodologia leggera ed adattiva:

Una metodologia si dice leggera se prevede lo svolgimento di un numero ridotto di attività e produzione di relativamente pochi elaborati (ma in quantità e di qualità sufficiente per il progetto di interesse)

una metodologia si dice adattiva se è in grado di gestire efficacemente cambiamenti e richieste di cambiamenti, ad esempio cambiamenti nei requisiti.

Processo recente e molto dibattuto


XP: Punti caratteristici (01)

� L’idea di fondo che legittima l’intero processo è l’insufficienza cronica di tempo tipica dei progetti

invece di non seguire assolutamente un processo, il che rischierebbe di produrre risultati assolutamente non desiderabili, probabilmente è più opportuno seguirne uno “intuitivo”, leggero, pragmatico e quindi molto operativo

� Tutte le fasi del ciclo di vita del software vengono compresse afavore dell’attività di codifica

l’evoluzione delle API del sistema si acquisisce leggendo direttamente il codice, il comportamento di oggetti complessi viene definito per mezzo della codifica di appositi casi di test, gli inconvenienti vengono mostrati attraverso i problemi emersi dall’esecuzione dei casi di test, ...


XP: Punti caratteristici (02)

� elevata importanza agli unit test

� prima di scrivere il codice effettivo è assolutamente necessaria la scrittura dei relativi casi di test

� La realizzazione di unit test equivale a dire che il comportamento viene analizzato e “modellato” a priori sempre attraverso codice

Quindi:

� Il processo di sviluppo equivale ad una continua reingegnerizzazione del software


XP: Vantaggi

� Utile se si lavora a progetti con cicli di consegna molto compressi

� Utile se si lavora a progetti con fattori di rischio tecnologicomolto elevati

� Ottimo strumento a supporto di persone intelligenti

� Utile nel realizzare opportuni frameWork

la collezione di classi via via prodotte viene immediatamente verificata ed eventuali lacune vengono alla luce rapidamente.

NOTA : Il processo non rifiuta completamente la fase di disegno, ma ne prevede l’utilizzo in casi estremi, quando non sia possibile codificare: in tutti gli altri casi l’attività di implementazione ha la precedenza.


XP: Svantaggi (01)

� complicato sottoporre il modello ad altre persone, al fine di ricevere qualche considerazione

� complicato considerare i modelli stessi come risorse preziose per il futuroESEMPIO: Si pensi agli Use Case o modelli di analisi e disegno presenti in organizzazioni bancarie che rappresentano veri e propri investimenti indipendenti dal linguaggio utilizzato per l’implementazione, di un valore elevatissimo per futuri sviluppi e reingegnerizzazioni

� Il team deve prevedere persone di talento, cooperative, dotate di buon affiatamento, coordinate da un Team Leader dotato di esperienza e capacità personali


XP: Svantaggi (02)

� L’XP non porta a produrre tutta una serie di modelli estremamente importanti per l’organizzazione in cui il sistema funzionerà

La metodologia RUP permette di realizzare, oltre al sistema stesso, tutta una serie di manufatti di estremo interesse, come per esempio il modello del business che può essere utilizzato per aggiornare il sistema, per future reingegnerizzazioni, per insegnare a nuovi dipendenti l’area di business, ecc. Per capirne l’importanza, basti pensare che mentre la tecnologia tende a rinnovarsi molto rapidamente, non altrettanto vale per il business, e quindi un buon modello può risultare valido per decine di anni


XP: Per tutti ?

� Progetti di dimensioni medio-piccole

� Team di buona qualità e di dimensioni medio/piccole

� Persone in grado di capire i limiti e le virtù del processo stesso


Riferimenti

� UML Distilled Guida rapida al linguaggio di modellazione standard Autore Fowler Martin, Editore Pearson Education ItaliaTitolo originale UML Distilled: a brief guide to the standard object modeling language, third edition (Addison Wesley)

BIBLIOGRAFIA

� The Unified Modeling Language - UserGuideAutore G. Booch, J. Rumbaugh, I. Jacobson, Editore Addison-Wesley

� UML e ingegneria del software - Dalla teoria alla praticaDownload: http://www.mokabyte.it/umlbook/index.htm

SITOGRAFIA

� http://www.rational.com/ Rational

� http://www.omg.org Object Management Group(per documenti ufficiali UML)

� Rational Unified ProcessAutore P. Kruchten, Editore Addison-Wesley

Modello a cascata Sviluppo iterativo del SW Unified Modeling Language ... - Di … ·...

Documents

Transcript of Modello a cascata Sviluppo iterativo del SW Unified Modeling Language ... - Di … ·...