DA UML A JAVA - Intranet DEIBhome.deib.polimi.it/sanpietr/SE/slides/UML1.pdf · classi superiori,...

Ingegneria del Software

DA UML A JAVA


The Unified Modeling Language

Molte discipline ingegneristiche dispongono di validi mezzi di rappresentazione (schemi, diagrammi di prestazioni e consumi, ...)

Il software non dispone ancora di tecniche efficaci per descriverne la struttura, le funzionalità e le prestazioni

UML cerca di rimediare a questa situazione

• UML è diventato uno standard di fatto per object-oriented modelling

design

• Una “famiglia di notazioni”


Class Diagram


Class Diagram

• Definiscono la visione statica del sistema

– classi

– relazioni tra classi

• associazione (uso)

• generalizzazione (ereditarietà)

• aggregazione (contenimento)

• È forse il modello più importante perché definisce gli

elementi base del sistema


Classi

• In UML una classe è composta da tre parti

– nome

– attributi (lo stato)

– metodi (il comportamento)

Professore

nome

cognome

create()

delete()

Professore

create()

delete()

Professore

nome

cognome

Professore


Professore

{abstract}

+ nome: String

# cognome: String

- età: integer = 32

+ visualizza()

- scegliCorso()

Professore

nome: String

cognome: String

età: integer

visualizza()

scegliCorso()

Professore

Visibilità


Classe

Attributo: visibilità nome: tipo [molteplicità] = default {stringa di proprietà}

Metodo: visibilità nome (lista parametri): tipo di ritorno {stringa di proprietà}

Visibilità: + public, - private, # protected, ~ friendly

Parametro: direzione nome: tipo = default

7

Dettagli classe


Traduzione

8

public class Persona { private String nome; private String cognome; private Date dataNascita; private static int numPersone; public boolean siSposa(Persona p) { … } public boolean compieAnni(Date d) { … } }

Classe UML e classe Java


Ereditarietà

• Le classi sono di solito organizzate in una gerarchia

• Le classi in cima alla gerarchia hanno caratteristiche

comuni a tutte le classi

• Le classi più in basso ereditano attributi e servizi dalle

classi superiori, ma possono essere specializzate se

necessario

• Ereditarietà è detta generalizzazione in UML



Interfacce

11

Interfacce


• Un package è una cartella che contiene altre entità

(oggetti, classi, altri package, …).

Pressure

controller

Temperature

controller

Alarm and

protection

Oxygen plant

(b) Package containing packages

Oxygen plant

(a) Package

symbol

UML package


Package

Decomposizione gerarchica e dipendenze tra package

13

Package


Corso CartellaStudente appare

Associazioni

• Un’associazione indica una relazione tra classi

– ad esempio persona che lavora per azienda

• Un’associazione deve avere un nome

• Il nome è solitamente un verbo (un etichetta al centro

della linea che definisce l’associazione)


Corso Studente

3 .. 10 0..*

Molteplicità

segue

La molteplicità definisce il numero di oggetti che prendono parte alla

relazione

La molteplicità dice:

Se l’associazione è obbligatoria oppure no?

Il numero minimo e massimo di oggetti che possono essere

relazionati ad un altro oggetto


Molteplicità (cont.)

1 Esattamente 1

* zero o più

0..1 zero o uno

m..n entro gli estremi specificati


Esempio1

class Persona {

…

private Casa casa;

…

}

class Casa {

…

private Persona[] persone;

…

}

17

- casa - persone

Associazioni e molteplicità in Java

Associazioni

sono attributi

impliciti (con

visibilità)


Persona Azienda

lavora

Impiegato DatoreDiLavoro

1..* 0..1

Ruolo

• Definisce il ruolo svolto nell’associazione


Utente Directory

proprietario

utente autorizzato

contenente

contenuto

0..*

0..*

0..* 0..*

0..1

Ruolo (cont.)

• Il ruolo diventa “importante” quando una classe è

coinvolta più volte nella stessa associazione


Esempio2

20

class Persona { private String nome; private String cognome; private Date dataNascita; private static int numPersone; public Persona marito; public Persona moglie; public boolean siSposa(Persona p) { … } public boolean compieAnni(Date d) { … } }

Associazioni riflessive e ruoli


Esempio3

21

Associazioni con ruolo e verso

class Persona {

private String nome;

private String cognome;

private String codFiscale;

private int stipendio;

}

class Banca {

private Persona[] clienti;

}

class Prestito {

private int ammontare;

private int rata;

private Date dataInizio;

private Date dataFine;

private Persona intestatario;

private Banca banca;

}


Corso Curriculum 1..*

Aggregazioni

• Le aggregazioni sono una forma particolare di

associazione. Una parte è in relazione con un oggetto

(part-of)

• La traduzione in Java è simile al caso delle associazioni


Slider Panel Button

Window

1

2

1

1

1

1 scrollbar body close

2

1 1

1

1

1

Composizioni

• Una relazione di composizione è un’aggregazione forte

– Le parti componenti non esistono senza il contenitore

• Creazione e distruzione avvengono nel contenitore

• I componenti non sono parti di altri oggetti


Composizione (Notazioni Alternative)

body:Panel

scrollbar: Slider

close: Button

Window

1

1

2

body

scrollbar

close

Window

1

1

2 Slider

Panel

Button


Analisi Orientata agli Oggetti

Object Modeling


Modello di un sistema

• Descrizione astratta del sistema di cui si stanno

analizzando i requisiti

• Modello è una specifica in cui è inclusa anche una

descrizione dell’ambiente in cui il sistema dovrà operare


System modelling

• Modellare il sistema (System modelling) aiuta gli analisti

a capire le funzionalità del sistema

• I modelli del sistema sono usati per comunicare con i

committenti

• Diversi modelli presentano il sistema da diverse

prospettive

– Esterna: Mostrare il contesto o l’ambiente

– Comportamentale (Behavioural): operazione svolte dal

sistema

– Strutturale: architettura del sistema


Object models

• Modelli a oggetti (Object models) descrivono il sistema in termini di classi di oggetti

• Una classe è un'astrazione di un insieme di oggetti come costituiti da attributi comuni e da servizi (operazioni) fornite da ogni oggetto.

• Modo naturale di descrivere le entità del mondo reale manipolate dal sistema

• Identificazione delle classi è un processo difficile che richiede una profonda conoscenza del domino dell'applicazione

• Le classi che rispecchiano il dominio dell'applicazione, sono riutilizzabili per definire sistemi diversi


Concetti base

• Oggetti

• Classi

• Relazioni tra classi

• Questi concetti si ritrovano nella (sono ispirati dalla)

Programmazione ad Oggetti, ma lo scopo è molto

diverso.

• Oggetti qui possono essere entità del mondo reale, non

solo elementi di un programmnon sono


Oggetti

• Un oggetto è un concetto, un’astrazione o una “cosa”

con un significato ben preciso per l’applicazione in

esame

• Un oggetto è un’entità:

– fisica

– concettuale

– software


Stato

• Lo stato rappresenta la condizione in cui si trova

l’oggetto

• Lo stato è definito dai valori delle proprietà (attributi)

• Gli oggetti possono essere suddivisi in:

– passivi (lista di nomi)

– attivi (orologio, persona)


Comportamento

• Determina come agisce e reagisce un oggetto

– cambiamenti di stato e “reazioni” verso altri oggetti

• È definito dall’insieme di operazioni che l’oggetto può compiere

Apriti !


Operazioni

• Un’operazione è un servizio fornito dagli oggetti della

classe.

• L’insieme delle operazioni definiscie il comportamento

• Tutte e sole le operazioni rilevanti per il dominio

applicativo

– Bancario

• ricevePrestito, riceveCredito, apreConto

– Medico

• faEsame, prendeMedicina, vaOspedale


Classi

• Una classe è un gruppo di entità identificato da un

insieme di caratteristiche comuni

• Una classe è un “modello” per descrivere oggetti con

proprietà simili

• La classe è un’astrazione della realtà

– enfatizza alcune caratteristiche

– tralascia altre proprietà


Esempi


Ascensore

Door

Elevator Shaft Floor

Scheduler Station

Button


Relazioni (associazioni)

• Oggetti e classi partecipano a relazioni ("associazioni" in

UML) con altri oggetti e classi

• Associazioni possono essere annotate con informazioni

che descrivono l'associazione

– Nessun significato formale…

• Associazioni possono anche indicare un oggetto è

associato con uno (o più) metodi o attributi di altri oggetti


Class Diagram…


Classificare le entità

• Utile minimizzare numero delle classi per migliorare produttività e riusco.

• Eseguire classificazione degli oggetti, identificando fattori in comune:

– funzione e comportamenti

– Qualità (attributi).

• Esempio: prima classificazione suddivide in tre gruppi: sensor, controller and actuator.

• Gli attuatori sono fra loro identici, ma I sensori hanno dettagli diversi

• Cosa fare?

Airspeed

Height

Attitude

Roll actuator

Yaw actuator

Pitch actuatorSystem

controller

(a) System Objects

Sensors

Airspeed

Height

Attitude

Controllers

System

Actuators

Roll

Pitch

Yaw

(b) Grouping of system objects


User class hierarchy N a m e

A d d re ss

P h on e

R e gi st ra t io n #

L i br a ry us e r

R e gi st e r ( )

D e - r e gi st e r ( )

A ff il ia t io n

Re a de r

I te m s o n l oa n

M a x. lo a ns

B o rro w e r

D e p a r tm e n t

D e p a r tm e n t ph on e

S t a ff

M a jo r s ub je c t

H o m e a d d re ss

S t ud e nt


Vantaggi ereditarietà per OOA

• Meccanismo di astrazione utile per classificare entità e trovare relazioni fra

entità simili

– Es.: vari tipi di sensori sono diversi ma hanno caratteristiche comuni,

fattorizzabili in una classe sensore, da cui le altre ereditano.

• Meccanismo di riuso, sia per l'analisi del dominio, che a livello di design e di

programmazione

• Il grafo dell'ereditarietà è sorgente di informazione organizzativa sul dominio

dell'applicazione e sui sistemi realizzati, utile anche documentazione

• Svantaggio: Problema di leggibilità

– classi non sono entrocontenute: occorre leggere anche le superclassi

per capirle…


Multiple inheritance

• Possibilità di ereditare da più classi

• Può portare a conflitti fra attributi o servizi con lo stesso nome

ereditati da classi diverse

# Ta pe s

T a lk in g bo ok

A u th or

E d it io n

P u bl ic a t io n d a t e

I S B N

B o ok

S p e ake r

D u ra t io n

Re c ord in g d a t e

V o ic e r e c or d in g


System and software design


Analisi vs. Design

OOA OOD Modello dei requisiti

Aggiunta di dettagli e decisioni progettuali

Punto di vista dell’utente Punto di vista del progettista

Transizione OOA -> OOD presenta spesso

discontinuita’: scelte architetturali.


Object-oriented Design

• La progettazione del software può essere descritta come

un insieme di oggetti software interagenti che gestiscono

il proprio stato e le proprie operazioni

• Vari modelli per descrivere OOD, e UML può essere

usato per rappresentarli


Vantaggi di OOD

• Manutenzione semplificata. Oggetti comprensibli come

entità stand-alone

• Oggetti sono componenti riusabili

• Per molti sistemi, c'è una chiara corrispondenza fra le

entità del "mondo reale" (persone, ruoli, dispositivi…) e

gli oggetti del sistema


Oggetti in OOD/OOP

• Oggetto: entità in memoria, con uno stato e un insieme

definito di operazioni che manipolano lo stato.

– lo stato è rappresentato dai valori in memoria degli attributi

dell'oggetto.

– Le operazioni forniscono servizi ad altri oggetti (clienti),

che li richiedono quando necessario.

• Oggetti sono creati secondo quanto definito nella classe

corrispondente.

– Una classe è quindi uno "stampo" per creare oggetti dello

stesso tipo.

– Include dichiarazioni di tutti gli attributi e servizi che

dovrebbero essere parte degli oggetti della classe.


Object-oriented development

• Object-oriented analysis, design and programming: correlate ma distinte

– OOA: sviluppare un modello a oggetti del dominio applicativo e individuare le responsabilità del sistema da sviluppare

– OOD: sviluppare un modello object-oriented di un sistema che implementa i requisiti

– OOP: realizzare un design object-oriented usando un linguaggio di programmazione OO (Java, C++,…)

• E' possibile utilizzare solo OOA, oppure solo OOA e OOD e poi implementare in linguaggio tradizionale come C (ma allora alcuni accorgimenti…)


Cenni ad altri diagrammi statici


Diagrammi dei componenti

Utili per “decomporre” il sistema in esame


Esempio

movimento

DisplayPulsantiera

Controllo SistemaAscensore

Piano

visualizzazioneposizione

visualizzazionerichieste

prenotazione

richieste


Diagramma di deployment

Cellulare2

JME JME

client.jarserver.jar

client.jar

Cellulare1

TCP/IP


Database server

prenotazioni.myd

Application server

gestPrenotazioni.ear

Web server

prenota.war

Cellulare

browser

http/Internet


Diagrammi di comportamento


Modellare il comportamento

• Comportamento: modalità di interazione fra oggetti

• Sequence diagrams sono utilizzati a tale scopo


Diagrammi di sequenza

I diagrammi di sequenza rappresentano interazioni tra oggetti

Materializzazione di scenari specifici

Sono utili per

Evidenziare le interazioni tra oggetti e quindi i metodi da associare alle diverse classi

Provare l’efficacia dei servizi identificati

56

Diagrammi di sequenza


Il caso più semplice

57


Cosa succede se …

58


Distribuzione di materiale in formato

elettronico

: L ib r a r y U s e r

E c a t :

C a ta l o g

L o o k u p

I ss u e

D i s p l ay

: L ib r a r y I te mL i b 1 :

N e t S e r v e r

I ss u e li c e n c e

A c c e p t li c e nc e

C o m p r e ss

D e l iv e r


Frame di interazione

ref

alt

opt

loop

par

neg

…

60

Frame di interazione


State Diagrams models

• Modellano il comportamento del sistema come risposta a

eventi interni e esterni

• Particolarmente adatti a sistemi reattivi e in tempo reale

(descrivono risposte a stimoli esterni)

• Stati = nodi, eventi= archi fra i nodi. Quando accade un

evento il sistema si sposta da uno stato all'altro


StateCharts

Gli Statecharts sono un'estensione degli automi a stati finiti,

tipicamente utilizzati per descrivere sistemi di controllo.

Dovuti a David Harel, primi anni ‘80.

Specificano tramite diagrammi (charts) il comportamento di

un sistema o di singoli oggetti

La compatezza della loro rappresentazione permette di

controllare l’esplosione degli stati


Caratteristiche

Una specifica e’ scomposta in vari oggetti comunicanti.

Ogni oggetto e’ un automa a stati finiti descritto in termini di:

Eventi a cui gli oggetti sono “sensibili” (segnali, chiamate di metodi, passaggio del tempo, cambi di stato di altri oggetti)

Azioni prodotte in risposta agli eventi

Transizioni di stato

Possibilità di descrivere evoluzioni parallele e cooperanti degli oggetti.

Ricca notazione grafica per rendere piu’ semplice la descrizione


StateCharts: blocchi base della notazione

Stato

Decomposizione OR

Decomposizione AND

azione

Transizione

evento [condizione]


Identificare gli stati

Analizzare tutti gli stati in cui un oggetto può trovarsi

Usare gli use case e gli scenari

Definire un livello di dettaglio giusto e omogeneo

Identificare gli attributi significativi

Individuare le condizioni limite


Esempio (senza stato finale):

centrale telefonica

Messaggio Vocale

Inattivo

Tono Pronto

Compos. Numero

ProntoA Connettere

Tono Libero

Connesso

Tono Occupato

Tono TimeOut

Chiamante.Aggancia

FineMessaggio

T

T Compone(n)

NumValido

NumNonValido

Occupato

Chiamante.Aggancia

Chiamante.Sgancia

Ricevente.Sgancia

Instradato

Compone(n)


Inizio e Fine

Inizio Bianco Muovere

Nero Muovere

Matto o Abbandono

Stallo o Accordo

Mossa Bianca

Mossa Nera

Vince Nero

Vince Bianco

Patta

Matto o Abbandono

Stallo o Accordo


Pronto Verde [incrocio.stato=libero]

InCorsa

Condizione Evento

Condizioni

Funzioni booleane sui valori degli oggetti

Opzionali, ma utili Utili quando non basta l'evento, ma si

vuole aggiungere un predicato

Anche evento e’ opzionale: ci puo’ essere solo condizione


Operazioni

Azioni

Operazioni che hanno durata istantanea

Tipicamente produzione di eventi

Sono associate alle transizioni di stato oppure all'ingresso o

all'uscita da uno stato

Attività

Sono operazioni con durata significativa

Sono associate ad uno stato

Continue o sequenziali

Possono essere descritte con linguaggio di programmazione


event3 [condizione1] / azione5

event4 [condizione2] / azione6

do: attività1

entry / azione1

exit / azione2

event1 / azione3

event2 / azione4

Nome

attributo1: tipo1 = val.iniziale

attributo2: tipo2 = val.iniziale

Stato Completo

In ogni stato si possono dichiarare variabili, da

inizializzare opportunamente.


right-mouse-down(location) [location in window] /

object:=pick-object(location) ^object.highlight() 0 Oggetti

selezionati

1 Oggetto

selezionato

Eventi (Generati da Azioni)

Spesso le azioni consistono nell'inviare un evento ad un

altro oggetto : questi sono detti eventi INTERNI


Eventi (2)

Gli eventi ESTERNI sono invece quelli non generati dal

sistema.

Gli eventi (interni e esterni) sono messi in una coda

(buffer FIFO) ed estratti uno alla volta.

Se nessuna transizione associata all’evento e’ in grado di

scattare, l’evento e’ perduto.

Attenzione a catene infinite di eventi in composizione

parallela (A invia evento e1 a B che in risposta invia e2

ad A che invia e1 a B, …)


State Diagram Piatti

La complessità cresce esponenzialmente

Descresce l’espressività e la comprensibilità

Diagrammi Strutturati

Favoriscono la sintesi e aumentano la leggibilità

Generalizzazione (macro stati)

Aggregazione (stati concorrenti)


Folle RetroMarcia

MarciaAvanti

Prima Seconda Terza

levaR

levaN

levaF levaN

accelera accelera

decelera decelera

ferma

Cambio Automatico

Diagrammi a stati strutturati

Un macro stato equivale ad una scomposizione Or degli stati

I sottostati ereditano le transizioni dei loro superstati


Altro es. di Decomposizione OR


History

History può essere associata a stati non foglia

Quando l’esecuzione lascia uno stato S con history

Si salva l’ultimo stato visitato S1 in S

Quando l’esecuzione ritorna in S

Si riparte da S1

H

A A1

A2

B


Registrazione Corsi

Creazione Selezione corsi

Selezione corsi extra

Sospeso

Salva

Sottometti

corsiE < 2

corsi < 4

sospendi

ricomincia

quit

corsiE = 2

giorni > 3

corsi = 4

H


Concorrenza di due attività

Guida Normale

do: guida

do: guida

do: sms

Guida distratta

sms clacson

Guida Attenta

do: guida piano invia


Sottostati Concorrenti. Decomposizione AND

lab1 lab2

progetto

scritto passato

Incompleto

non passato


Oggetti Compositi

Accendino

Serbatoio

Fornello

Vuoto

Serbatoio

Chiuso

Acceso Aperto

Fornello

carica

Pieno

[gas = 0]

[gas > 0]

apri

scintilla

chiudi


Interazione fra Componenti

Vuoto

Serbatoio

Chiuso

Acceso Aperto

Fornello

carica

Pieno

[gas = 0]

[gas > 0]

apri

[Serbatoio.stato == Pieno]

chiudi

scintilla


Stubbed Transitions

A

B

C

D

E

F

W

A

B C

D

W


Microwave oven model

F u ll pow e r

E n a b l e d

d o : op e r a te

o ve n

F u ll

p ow e r

H a l f

p ow e r

H a l f

p ow e r

F u ll

p ow e r

N u m b er

T i m e r

D o or

o pe n

D o or

c lo se d

D o or

c lo se d

D o or

o pe n

S t a rt

d o : se t po w e r

= 6 00

H a l f p ow e r

d o : se t po w e r

= 3 00

S e t ti m e

d o : ge t nu m be r

e x i t: s e t t im e

D i s ab l ed

O p e r a ti on

T i m e r

C a nc e l

W a it in g

d o : d i sp la y

ti m e

W a it in g

d o : d i sp la y

ti m e

d o: d i sp la y

' R e a dy '

d o : d i sp la y

' W a it in g '


Microwave oven operation

C o ok

d o: run

ge ne ra t or

D o ne

d o: bu z z e r on

f or 5 s e c s.

Wa it in g

A l a rm

d o: d i sp la y

ev e nt

d o: c he c k

s ta tu s

C h ec k in g

T u rn ta b le

fa ul t

E m i tt e r

f a ul t

D i s ab le d

O K

T i m eo ut

T i m e

O p e r at i on

D o or

o pe nC a nc e l

Date post:	13-Apr-2018
Category:	Documents
Upload:	dokien
View:	215 times
Download:	2 times

DA UML A JAVA - Intranet DEIBhome.deib.polimi.it/sanpietr/SE/slides/UML1.pdf · classi superiori,...

Documents