di Milanohomes.di.unimi.it/piuri/pages/didattica/SInformatici/mat/...Viene introdotto il concetto di...

PolitecnicoPolitecnicodi Milanodi Milano

UMLUML

UML: Unified Modeling Language

Notazione object-oriented utilizzabile durante le fasi di analisi e design di un sistema.

E' diventato uno standard di fatto per object-oriented modelling

Evoluzione e unificazione di tre notazioni: Booch (dell'omonimo autore), OMT (di Rumbaugh) e OOSE (di Jacobson).

UML è indipendente da qualsiasi linguaggio di programmazioneUML è utilizzabile in domini applicativi diversi e per progetti di diverse dimensioniUML è estendibile per modellare meglio le diverse realtà

Paradigma Object OrientedParadigma Object Oriented

E’ un paradigma di programmazione le cui caratteristiche salienti sono:

IncapsulamentoViene introdotto il concetto di classe: un tipo di dato a cui sono associate anche le funzioni di accesso ai datiOggetto: istanza di una classeSi permette l’accesso ai dati solo tramite le opportune funzioni offerte dalla classe

EreditarietàSi possono definire classi che specializzano altre classi

– Esempio: la classe vettore di interi “eredita” dalla classe vettore

PolimorfismoBinding dinamico

Diagrammi UMLDiagrammi UML

Viste staticheUse Case DiagramClass DiagramComponent DiagramDeployment Diagram

Viste DinamicheState DiagramActivity DiagramCollaboration Diagram

Interaction DiagramSequence Diagram


Use Case Diagram Use Case Diagram

Definizione dei RequisitiDefinizione dei Requisiti

Il primo passo di “qualsiasi” processo di sviluppo è la definizione dei requisiti

Definizione del Business ModelSolitamente informale e in linguaggio naturale

Jacobson (OOSE) propone una notazione particolare che è confluita in UML

Use Case Diagram

Use CasesUse Cases

Definiscono il comportamento del sistemaLe funzionalità (processi) principaliCome il sistema agisce e reagisce

DescrivonoIl sistemaL’ambiente Le relazioni fra sistema e ambiente

Diversi livelli di dettaglioScomposizione gerarchica simili ai DFD

Elementi FondamentaliElementi Fondamentali

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

Scambia informazioni con il sistemaFornisce input o riceve output dal sistema

Use Case: è un’unità funzionale parte del sistema

Relazioni FondamentaliRelazioni Fondamentali

interazione indica relazioni tra attori e casiuses indica l’uso di una certa funzionalità (utile quando funzionalità simili sono presenti in diversi contesti)extends definisce una funzionalità per estensione di una funzionalità già esistente

<uses>

<extends>

Esempio: registrazione CorsiEsempio: registrazione Corsi

All’inizio dell’anno accademico, l’ufficio amministrativo dell’università fornisce agli studenti la lista di corsi disponibili, attraverso un sistema di registrazione. Il sistema deve consentire agli studenti di selezionare quattro corsi fra quelli disponibili. In aggiunta ogni studente deve indicare due alternative. Nessun corso può avere più di 10 studenti. Corsi con meno di 3 studenti vengono cancellati automaticamente.

Registrazione Corsi (cont.)Registrazione Corsi (cont.)

I professori devono poter accedere al sistema per indicare i corsi in cui vorrebbero insegnare e 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.

Cambiamento Organizzazione Corso

Richiesta Iscritti

Professore

Selezione Corso

Gestione Professori

Gestione Studenti

Archivio

Gestione Corsi

Richiesta Catalogo Corsi

Cambiamento Piano studi

Studente

Registrazione CorsiUfficio Contabile

Registrazione CorsiRegistrazione Corsi

ActorActor

Gli attori identificano i ruoliPiù utenti con lo stesso ruoloPiù ruoli per il medesimo utente

Utili per configurare il sistema in funzione dei ruoli che accedono alle funzioni di alto livello

Definizione dei permessi concessi agli utenti in base al ruolo

Utili per tracciare i requisiti del sistemaChi usa cosaRisoluzione dei conflitti fra ruoliDefinizione esigenze di sicurezza e riservatezza

Use CaseUse Case

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

Gli obiettivi: ciò che il sistema dovrebbe fare secondo gli utentiLe interazioni: cosa vorrebbero (potrebbero) fare i diversi utenti

Gli use case di alto livello sono volutamente generici

non introdurre prematuramente scelte progettuali

Use Case (cont.)Use Case (cont.)

Come individuare gli use caseAnalisi degli eventi esterni

Gli eventi rilevanti devono suscitare reazioni del sistema, cioè use case

Analisi degli attori Un attore può essere il beneficiario di uno use caseUn attore può essere coinvolto in uno use caseUn attore può essere il controllore di uno use caseUn attore può semplicemente essere informato del “completamento” di uno use case

Use Case (cont.)Use Case (cont.)

Il processo di definizione degli use case è iterativoSi inizia identificando i comportamenti più sempliciSi descrivono i comportamenti alternativi e più complessi

Quando smettere?Un buon livello di dettaglio facilità tutte le attività successiveTroppi dettagli

Complicherebbero inutilmente la descrizioneIntrodurrebbero prematuramente scelte progettualiPrecluderebbero la visione d’insieme

ExtendsExtends

Extends indica che uno use case è simile a un altro ma è più specifico.Si descrive lo use case più specifico per differenze rispetto a quello più generaleEsempi

Pagamento prodotto e pagamento con carta di creditoCalcola prezzo prodotto e calcola prezzo scontato

Extends (cont.)Extends (cont.)

Partire dal caso più generale (relativamente al problema)“Scovare” le varianti più specifiche in base a

Differenze rispetto al caso baseTrattamenti specificiLavoro aggiuntivo

Esplicitare le specializzazioni significative rispetto al caso normale

Miglior comprensibilitàMaggior riuso

UsesUses

Uses fattorizza attività ricorrenti e condivise Analogie con

Chiamata a sottoprocedura in un linguaggio di programmazione

EsempiLa richiesta del numero di CC per ogni operazione bancariaLa consultazione del catalogo di una bibliotecaLe funzioni matematiche più complesse (sin, cos, log, ecc.)

cliente

impiegato

Gestione credito

Rich. ordine Ordine via Internet

extends

Dati cliente

uses

Disp. prodotto

uses

Mod. pagamento

uses

uses

Un esempioUn esempio

RiassumendoRiassumendo

Extends (al contrario, Generalization)Descrive una specializzazione rispetto al caso normaleFacilita la fattorizzazione (riuso) di comportamenti “simili”

Uses (al contrario, Include)Identifica un componente (parte) di un caso più complessoMassimizza ed evidenzia i componenti riutilizzabili

DocumentazioneDocumentazione

Per ogni use case:Titolo: Computo tasseAutori: Pluto e TopolinoDescrizione: Quando le iscrizioni di uno studente sono state accettate si inviano le informazioni all’ufficio contabileAttori: Ufficio contabilePre-condizioni: Studente registratoPost-condizioni: Non identificateScenari:.....

ScenariScenari

Uno scenario è un’istanza di uno use caseÈ una ”esecuzione” particolare dello use caseRappresenta il comportamento (le azioni e gli eventi) del sistema nel caso particolare considerato

Gli scenari definiscono requisiti di più basso livello rispetto agli use caseGli scenari sono solitamente definiti in linguaggio naturaleUML propone una notazione particolare

Interaction Diagram

ScenariScenari

Ogni use case dovrebbe essere corredato da un insieme di scenari

Scenari principali (più possibile) Tutto funziona correttamente

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

Quanti scenari si devono definire?Servono tanti scenari quanti sono quelli necessari per capire il corretto funzionamento del sistema e le eccezioni che si ritengono significative in durante l’analisi

Oltre l’Analisi dei RequisitiOltre l’Analisi dei Requisiti

Convalida del sistemaGli use case possono essere utilizzati per ricavare i dati di test con cui convalidare il sistema

Ogni use case rappresenta una funzionalità che andrebbe verificata

Gestione del progettoGli use case propongono una “nuova” unità di misuraGli use case potrebbero essere utili per

Organizzare il progettoStimare la complessità

EsercizioEsercizio

Si definisca un semplice Use Case Diagram per modellare il sistema informativo di una società di autonoleggio. Il sistema deve gestire

le prenotazioni (sia telefoniche, che via Internet), la richiesta diretta di un’autovettura, la fatturazione, l’invio di solleciti in caso di ritardo nella riconsegna, e il parco macchine.


Gli use caserappresentano i requisiti del sistemaforniscono una base per la pianificazione ed il controllo del progetto

Il processo di definizione è un processo iterativoDal generale al grado di dettaglio richiesto

L’istanziazione degli use case avviene definendo gli scenari corrispondenti ad ogni use case

Interaction DiagramInteraction Diagram

Interaction DiagramInteraction Diagram

Descrivono il comportamento dinamico di un gruppo di oggetti che “interagiscono” per risolvere un problemaSono utilizzati per “formalizzare” gli scenari in termini

Entità (oggetti)Messaggi scambiati (metodi)

UML propone due diversi tipi di Interaction Diagram

Sequence DiagramCollaboration Diagram

Sequence DiagramSequence Diagram

Evidenziano la sequenza temporale delle azioniNon si vedono le associazioni tra oggettiUsabili in due forme diverse

La forma generica: tutte le sequenze (esecuzioni) possibiliLa forma d’istanza: una sequenza particolare (consistente con quella generica)

Paperino Selettore Informatica

scegli informatica

disponibile?

aggiungi Paperino

conferma registrazione

Sequence DiagramSequence Diagram

Sequence DiagramSequence Diagram(Sistemi in Tempo Reale)(Sistemi in Tempo Reale)

Chiamante Scambio Chiamato

inizio

tono libero

componi n....

instradamento

tono attesa tel suona

risposta

stop attesa stop attesa

ab

c

d

d’

{b-a < 1 sec.}{c-b < 10 sec.}

{d’-d < 5 sec.}

Il ritardo è dovutoall’uso della rete

A questo punto iniziala conversazione

EsercizioEsercizio

Si definisca un semplice Sequence Diagram per modellare il prelievo di denaro, supponiamo 200

Euro, da uno sportello Bancomat

Sequence DiagramSequence Diagram(Processi Concorrenti e Attivazioni)(Processi Concorrenti e Attivazioni)

Obj1:C1op()

doit(z)

Obj3:C3

Obj2:C2

Obj4:C4

[x>=0] foo(x)

[x<0] bar(x)doit(w)

more()

MessaggiMessaggi

SincroniChi invia il messaggio aspetta la conclusione dell’operazione richiesta (chiamata di procedura)

Asincroni Equivalenti a qualche forma di comunicazione tra processi)Chi invia il messaggio continua, senza aspettare la conclusione dell’operazione richiesta (comunicazione fra processi)


Uno scenario può essere rappresentato per mezzo di un Interaction Diagram

I Sequence Diagram mettono più enfasi sulla sequenza delle operazioni e possono indicare l’esistenza dei diversi oggetti

I diagrammi vanno completati con commenti testuali per fornire ulteriori dettagli


Class DiagramClass Diagram

Class DiagramClass Diagram

Definiscono la visione statica di un dominio classirelazioni tra classi

associazione (uso)generalizzazione (ereditarietà)aggregazione (contenimento)

È forse il modello più importante perché definisce gli elementi base del dominio

ClassiClassi

Una classe è composta da tre partinomeattributi (lo stato)metodi (il comportamento)

Professore

nomecognome

create()delete()

Professore

create()delete()

Professore

nomecognome

Professore

Catalogo Corsi

Professore

Elenco Iscritti

Corso Studente

Cartella Studente

Le Le classiclassi

TrovareTrovare le le classiclassi e e gligli oggettioggetti

Dove guardareosservazioni di prima mano, ascoltare attivamente, considerare risultati precedenti e altri sistemi, leggere a volontà, prototipi

Cosa cercarestrutture, altri sistemi, dispositivi, cose ed eventiricordati, ruoli, procedure operative, luoghi ed unitàorganizzative

Cosa considerarememoria e comportamento necessari, molteplicità di attributi e di istanze, attributi e metodi semprepresenti, requisiti del dominio

Esempio della bibliotecaEsempio della bibliotecaIdentificazione di classi e oggetti: i candidatiIdentificazione di classi e oggetti: i candidati

La biblioteca è organizzata in settori, a ciascuno dei quali corrisponde un argomento (storia, narrativa, saggistica, arti pratiche, scienza, tecnologia, fantascienza, musica, ecc.).I settori contengono documenti di vario genere: libri, riviste, materiale audio (dischi, cd, cassette) e video (cassette e video dischi). I documenti risiedono in scaffali opportunamente numerati.La biblioteca concede prestiti (fino a 15 giorni) e un singolo rinnovodi una settimana. I prestiti sono concessi agli utenti registrati. La registrazione è effettuata automaticamente su domanda dell'utente. Se la restituzione dei documenti in prestito non avviene entro termine stabilito la biblioteca avverte l’utente tramite sollecito. Se anche questa azione non sortisce effetto, si passa alla sospensionedal prestito dell’utente.


Non tutti i documenti sono prestabili, per vari motivi (sono rari o preziosi o devono essere sempre consultabili). Le riviste contengono collezioni di articoli, che sono memorizzati singolarmente nel database di sistema. Le riviste sono presenti in copia unica e non sono prestabili.I documenti sono descritti da appositi cartellinicontenuti in schedari che gli utenti possono consultare. Ogni cartellino riporta: titolo, autore, editore e anno di emissione del documento ed altre informazioni per ciascun documento.


biblioteca settore argomento documentolibro rivista mat. audio discoCD cassetta video video cassettavideo disco scaffale prestito giornorinnovo settimana utente azionetermine registrazione collezione articolodatabase copia cartellino schedariotitolo autore editore informazionianno descrizione restituzione sollecitosospensione sistema

Esempio della bibliotecaEsempio della bibliotecaL’insieme iniziale di classiL’insieme iniziale di classi

biblioteca settore argomento documentolibro rivista audio discoCD cassetta video video cassettavideo disco scaffale prestito giornorinnovo settimana utente azionetermine registrazione collezione articolodatabase copia cartellinoschedariotitolo autore editore informazionianno descrizione restituzione sollecitosospensione sistema

AttributiAttributi

Un attributo è una caratteristica della classeGli attributi non hanno identitàOgni attributo deve essere definito in modo precisoAttributi buoni per Studente

Nome, Cognome, …

Attributi cattiviCorsiScelti

nomecognome

Professore

età

id nomecognome

Professore

età

Attributi (cont.)Attributi (cont.)

Gli oggetti avranno una loro identità, non bisogna aggiungerla

Codice fiscale?

Attributi (cont.)Attributi (cont.)

Nomi che non sono diventati classiDurante la definizione delle classi stesseConoscenza del dominio applicativo

Persona (ambito bancario)nome, cognome, codiceFiscale, numeroConto

Persona (ambito medico)nome, cognome, allergie, peso, altezza

Attributi DerivatiAttributi Derivati

Calcolati, non memorizzatiSi usano quando i loro valori variano frequentemente e la correttezza (precisione) del valore è importanteIl valore viene calcolato in base ai valori di altri attributi

età = f(dataDiNascita, oggi) area, perimetro = f(vertici)

Attributi Derivati (cont.)Attributi Derivati (cont.)

PersonadataNascita : Date

/ età : int

1..*Divisione

1..*

Persona1..*

lavora

Azienda

1..*

/ impiega{età = oggi - dataNascita}

Operazioni (Metodi)Operazioni (Metodi)

Un operazione è una trasformazione applicabile ad un’istanza di una classeTutte e sole le operazioni rilevanti per il dominio applicativo

BancarioricevePrestito, riceveCredito, apreConto

MedicofaEsame, prendeMedicina, vaOspedale

ClassiClassi(Visibilità)(Visibilità)

Professore{abstract}

+ nome: String# cognome: String - età: integer = 32

+ visualizza()- scegliCorso()

Professore

nome: Stringcognome: Stringetà: integer

visualizza()scegliCorso()

Professore

Template Class

Instantiated Class <base>

Base

Classi ParametricheClassi Parametriche(Template)(Template)

Modo sintetico per definire un insieme di classi “simili”

Le singole classi si ottengono istanziando i parametri contenuti nella definizione

Vettore

T,k:integer

Vettore<char,3>

Pentagono

<<bind>> (Vertici,5)

IstanziazioneIstanziazione

<<utility>>Matematica

log(int):realsin(Ang):realsqrt(int):realpower(real, int): real

Classi UtilityClassi Utility

Contengono metodi di classe e non di istanza (come i metodi static di Java)

InterfacceInterfacce

Definiscono il comportamento esterno di una classe

String

uguale(String):Booleanhash():Integer

HashTable

Hashable

Comparable

AssociazioniAssociazioni

Un’associazione definisce un canale di comunicazione bidirezionale fra le due classiLa molteplicità definisce il numero di istanze che prendono parte alla relazioneI link sono istanze delle associazioni

Un link connette due oggettiUn'associazione connette due classi

Corso CartellaStudenteappare

AssociazioniAssociazioni

Un’associazione indica una relazione tra classiad esempio persona che lavora per azienda

Un’associazione deve avere un nomeIl nome è solitamente un verbo (un etichetta al centro della linea che definisce l’associazione)

Corso Studente

3 .. 100..*

MolteplicitàMolteplicità

La molteplicità dice:Se l’associazione è obbligatoria oppure no?Il numero minimo e massimo di oggetti che possono essere relazionati ad un altro oggetto

segue

Molteplicità (cont.)Molteplicità (cont.)

1Esattamente 1

* zero o più

0..1 zero o uno

m..n entro gli estremi specificati

Persona Aziendalavora

Impiegato DatoreDiLavoro

1..* 0..1

RuoloRuolo

Definisce il ruolo svolto nell’associazione

Utente Directoryproprietario

utente autorizzato

contenente

conteneuto

0..*

0..*

0..* 0..*0..1

Ruolo (cont.)Ruolo (cont.)

Il ruolo diventa “importante” quando una classe è coinvolta più volte nella stessa associazione

Studente Corso

Frequenzapercentualeprofitto

1..* 1..*

AttributiAttributi

Alcune proprietà potrebbero appartenere all’associazione e non alle parti coinvolte

Classe A Classe B

Classe C

Classe D

operationZ()<<friend>>

<<friend>>

<<calls>>

<<instantiates>>

DipendenzaDipendenza

Relazione che indica una dipendenza tra classi (es. se cambia la definzione di B, questo influenza A, C, D)

Corso Curriculum1..*

AggregazioniAggregazioni

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

SliderPanel Button

Window

1

2

1

1

1

1scrollbar body close

2

1 1

1

1

1

ComposizioniComposizioni

Una relazione di composizione è un’aggregazione forte Le parti componenti non esistono senza il contenitore

Creazione e distruzione avvengono nel contenitoreI componenti non sono parti di altri oggetti

ComposizioneComposizione(Notazioni Alternative)(Notazioni Alternative)

body:Panel

scrollbar: Slider

close: Button

Window

1

1

2body

scrollbar

close

Window

1

1

2Slider

Panel

Button

Aggregazione

Corso

Precedenze

Parte

Associazioni riflessiveAssociazioni riflessive

Un’associazione è riflessiva se coinvolge oggetti della stessa classeIndicano oggetti multipli della stessa classe che sono in relazione fra loro

Persona

Studente Professore

Ereditarietà (Generalizzazione)Ereditarietà (Generalizzazione)

Esplicita eventuali comportamenti comuniÈ possibile dover:

Aggiungere nuove proprietà alle classiRidefinire/modificare operazioni esistenti

ruolo ruolo

VeicoliTerrestri

Veicoli

VeicoliPropUmana

Macchina Bicicletta BarcaARemi

{propulsione}{overlapping}{superficie}

EreditarietàEreditarietà(Sottoclassi non Disgiunte)(Sottoclassi non Disgiunte)

Classi AstratteClassi Astratte

Poligono{abstract}

Cerchio

Figura{abstract}

Triangolo Quadrato

Catalogo Corsi

Professore

Elenco Iscritti

Corso Studente

Cartella Studente

Precedenze

Registrazione CorsiRegistrazione Corsi

SoluzioneSoluzione con con molteplicitamolteplicita’’

Catalogo Corsi

Professore

Elenco Iscritti

Corso Studente

Cartella Studente

3..10

Precedenze

0..*0..*

1..*1..*

1..1

1..1

1..1

1..1

1..1

0..*

1..*


Le classi sono l’elemento fondamentale di qualsiasi sistema ad oggettiIn un Class Diagram si definiscono

Le classiLe relazioni fra classi

AssociazioniAggregazioniSpecializzazioni/generalizzazioni


UsoUso di UML di UML nellanella creazionecreazione di un di un documentodocumento di di progettoprogetto

Struttura di un documento di Struttura di un documento di descrizione dei requisitidescrizione dei requisiti

Costituito da 3 parti:Descrizione del dominio applicativoDescrizione dei requisiti

effetti che il software deve esercitare sul dominio applicativo.

Specifica (design dell’interfaccia) della “macchina” da realizzare.

Descrizioni e specifiche possono essere scritte in qualsiasi linguaggio (informale, semi-formale, formale)

Come Come procedereprocedere??

Descrizione del dominio applicativoClass diagram per identificare i fatti e le relazioni trafattiUso degli Actor per identificare gli attori che operanonel dominio applicativo

Descrizione dei requisitiUse case per descrivere gli effetti che il software deve esercitare sul dominio applicativo

Specifica dei requisitiScenari ed interaction diagram

EsempioEsempio 1: 1: svilupposviluppo di di un’agendaun’agendacooperativacooperativa

Un’azienda di piccole dimensioni commissiona ad una software house lo sviluppo di un’agendadestinata all’uso da parte dei dipendentiL’agenda deve consentire agli utenti di teneretraccia degli appuntamenti e delle scadenzeimportanti che li riguardanoL’agenda deve supportare gli utentinell’organizzazione di meeting interni all’aziendaVincoli che possono originare requisiti extra-funzionali (vedremo dopo)

I dipendenti dell’azienda sono dotati di PC con sistema operativo Windows.L’azienda è cablata con una rete Ethernet a 100Mb

Use caseUse case

proponente partecipanteFissa Riunione

Inserisci impegno

Visualizza agenda

Cancella impegno

utente

partecipante

Proponi riunione

proponente

GestisciRisposta

Dettaglio di Fissa Riunione

Rappresentazione del dominio del problema: il diagramma delle classi

Appuntamento

Personale Lavoro

Impegno

ImpiegatoAgenda

0..n

1..n

0..n

1..n 11

Riunione

Ha a disposizione

11

ImpegnoConDurata ScadenzaData

Inizia

Finisce

Rappresentazione del dominio del problema: scenario di proposta di una riunione

: proponenteagenda : Agenda

agendaCol lega : Agenda

directoryAgende : partecipante

proponi riunione

AgendaDi(nome)

proponi riunioneProponi riunione

conferma riunioneconferma riun ione

noti fica conferma

Esempio 2: un sistema di controlloEsempio 2: un sistema di controllo

A simple system:a controller uses a sensor with an analog-to-digital converter to acquire information. The controller then uses an actuator to affect its environment. The system may use a temperature sensor to activate either a heater or a fan for closed-loop control. Additionally, it may use a pressure sensor to provide information about a gas line that it uses to control a valve with a stepper motor.

Rappresentazione del dominio del problema: il diagramma delle classi

EsercizioEsercizio

Completare il documento dei requisiti aggiungendogli opportuni use cases e scenari

di Milanohomes.di.unimi.it/piuri/pages/didattica/SInformatici/mat/...Viene introdotto il concetto di...

Documents

Transcript of di Milanohomes.di.unimi.it/piuri/pages/didattica/SInformatici/mat/...Viene introdotto il concetto di...