Ingegneria del Software DA UML A JAVA

Transcript

1 DA UML A JAVA

2 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

3 Class Diagram

4 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

5 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 Professore nome cognome

6 Visibilità Professore Professore nome: String cognome: String età: integer visualizza() sceglicorso() Professore {abstract} + nome: String # cognome: String - età: integer = 32 + visualizza() - sceglicorso()

7 Classe Ingegneria del Software Dettagli 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

8 Traduzione Ingegneria del Software Classe UML e classe Java 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) { } } 8

9 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

10

11 Interfacce Ingegneria del Software Interfacce 11

12 UML package Oxygen plant Oxygen plant Pressure controller Alarm and protection (a) Package symbol Temperature controller (b) Package containing packages Un package è una cartella che contiene altre entità (oggetti, classi, altri package, ).

13 Package Ingegneria del Software Package Decomposizione gerarchica e dipendenze tra package 13

14 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 appare CartellaStudente

15 Molteplicità 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 Corso segue Studente 0..*

16 Molteplicità (cont.) 1 Esattamente * zero o più zero o uno m..n entro gli estremi specificati

17 Esempio1 Associazioni e molteplicità in Java - persone - casa Associazioni sono attributi impliciti (con visibilità) class Persona { private Casa casa; } class Casa { private Persona[] persone; } 17

18 Ruolo Definisce il ruolo svolto nell associazione Persona lavora 1..* 0..1 Impiegato DatoreDiLavoro Azienda

19 Ruolo (cont.) Il ruolo diventa importante quando una classe è coinvolta più volte nella stessa associazione Utente proprietario 0..* utente autorizzato 0..* contenente 0..* Directory 0..* contenuto 0..1

20 Esempio2 Ingegneria del Software Associazioni riflessive e ruoli 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) { } 20

21 Esempio3 Ingegneria del Software 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; } 21

22 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 Corso 1..* Curriculum

23 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 Window scrollbar Slider 2 body 1 Panel close 1 Button

24 Composizione (Notazioni Alternative) Window Window 2 body:panel 1 scrollbar: Slider 1 body 2 scrollbar Panel Slider close: Button 1 1 close Button

25 Analisi Orientata agli Oggetti Object Modeling

26 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

27 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

28 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

29 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

30 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

31 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)

32 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!

33 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

34 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à

35 Esempi

36 Ascensore Shaft Elevator Floor Door Station Scheduler Button

37 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

38 Class Diagram

39 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 Roll actuator Height System controller Pitch actuator Attitude Yaw actuator (a) System Objects Sensors Airspeed Height Attitude Controllers System Actuators Roll Pitch Yaw (b) Grouping of system objects

40 L i br a ry us e r N a m e A d d re ss P h on e R e gi st ra t io n # User class hierarchy R e gi st e r () D e -r e gi st e r () Re a de r A ffil ia t io n B o rro w e r Ite m s o n l oa n M a x. lo a ns S t a ff D e p a rtm e n t D e p a rtm e n t ph on e S t ud e nt M a jo r s ub je c t H o m e a d d re ss

41 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

42 Multiple inheritance Possibilità di ereditare da più classi Può portare a conflitti fra attributi o servizi con lo stesso nome ereditati da classi diverse B o 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 V o ic e re c or d in g S p e ake r D u ra t io n Re c ord in g d a t e T a lk in g bo ok # Ta pe s

43 System and software design

44 Analisi vs. Design OOA Modello dei requisiti Punto di vista dell utente OOD Aggiunta di dettagli e decisioni progettuali Punto di vista del progettista Transizione OOA -> OOD presenta spesso discontinuita : scelte architetturali.

45 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

46 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

47 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.

48 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 )

49 Cenni ad altri diagrammi statici

50 Diagrammi dei componenti Utili per decomporre il sistema in esame

51 prenotazione Esempio Piano Pulsantiera Display visualizzazione richieste richieste visualizzazione posizione Ascensore Controllo Sistema movimento

52 Diagramma di deployment Cellulare1 Cellulare2 client.jar server.jar JME TCP/IP client.jar JME

53 Cellulare browser http/internet Web server prenota.war Application server gestprenotazioni.ear Database server prenotazioni.myd

54 Diagrammi di comportamento

55 Modellare il comportamento Comportamento: modalità di interazione fra oggetti Sequence diagrams sono utilizzati a tale scopo

56 Diagrammi di sequenza 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

57 Il caso più semplice 57

58 Cosa succede se 58

59 Distribuzione di materiale in formato elettronico E c a t : C a ta l o g : L ib r a r y I te m L i b 1 : N e t S e r v e r : L ib r a r y U s e r L o o k u p D i s p l ay I ss u e 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

60 Frame di interazione Frame di interazione ref alt opt loop par neg 60

61 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

62 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

63 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

64 StateCharts: blocchi base della notazione Stato Decomposizione OR evento [condizione] azione Decomposizione AND Transizione

65 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

66 Esempio (senza stato finale): centrale telefonica Chiamante.Aggancia Inattivo Chiamante.Aggancia Chiamante.Sgancia Tono T Pronto Tono TimeOut Compone(n) Compos. Numero Compone(n) T NumNonValido Messaggio Vocale Tono Occupato Occupato ProntoA Connettere NumValido Connesso Ricevente.Sgancia Tono Libero Instradato FineMessaggio

67 Inizio e Fine Inizio Bianco Muovere Matto o Abbandono Stallo o Accordo Vince Nero Mossa Bianca Mossa Nera Stallo o Accordo Patta Nero Muovere Matto o Abbandono Vince Bianco

68 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 Evento Condizione Pronto Verde [incrocio.stato=libero] InCorsa

69 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

70 Stato Completo In ogni stato si possono dichiarare variabili, da inizializzare opportunamente. Nome attributo1: tipo1 = val.iniziale attributo2: tipo2 = val.iniziale do: attività1 entry / azione1 exit / azione2 event1 / azione3 event2 / azione4 event3 [condizione1] / azione5 event4 [condizione2] / azione6

71 Eventi (Generati da Azioni) Spesso le azioni consistono nell'inviare un evento ad un altro oggetto : questi sono detti eventi INTERNI 0 Oggetti selezionati right-mouse-down(location) [location in window] / object:=pick-object(location) ^object.highlight() 1 Oggetto selezionato

72 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, )

73 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)

74 Diagrammi a stati strutturati Un macro stato equivale ad una scomposizione Or degli stati I sottostati ereditano le transizioni dei loro superstati Cambio Automatico levaf Folle levan levar levan RetroMarcia MarciaAvanti ferma accelera accelera Prima Seconda Terza decelera decelera

75 Altro es. di Decomposizione OR

76 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 A A1 B A2 H

77 Registrazione Corsi Creazione H corsi < 4 Selezione corsi corsi = 4 corsie < 2 Selezione corsi extra sospendi ricomincia corsie = 2 Sospeso giorni > 3 Salva quit Sottometti

78 Concorrenza di due attività Guida distratta Guida Normale do: guida sms do: guida do: sms clacson invia Guida Attenta do: guida piano

79 Sottostati Concorrenti. Decomposizione AND Incompleto lab1 lab2 scritto passato progetto non passato

80 Oggetti Compositi Accendino Serbatoio Fornello Vuoto carica [gas = 0] Pieno [gas > 0] Serbatoio Fornello Chiuso apri chiudi Aperto Acceso scintilla

81 Interazione fra Componenti carica Vuoto [gas = 0] Fornello apri Chiuso chiudi Serbatoio Pieno [gas > 0] Aperto scintilla [Serbatoio.stato == Pieno] Acceso

82 Stubbed Transitions A B E F W C D A B W C D

83 Microwave oven model F u ll p ow e r F u ll pow e r d o: se t po w e r = 6 00 W a it in g T i m e r d o: di sp la y ti m e F u ll p ow e r S e t ti m e d o: ge t nu m be r e xi t: s e t t im e N u m b er O p e r a ti on d o: op e r a te o ve n H a l f H a l f p ow e r p ow e r T i m e r D o or c lo se d C a nc e l D o or S t a rt H a l f p ow e r o pe n E n a bl e d D o or o pe n W a it in g d o: se t po w e r = 3 00 D o or c lo se d d o: di sp la y ' R e a dy ' d o: di sp la y ti m e D i s ab l ed d o: di sp la y ' W a it in g'

84 Microwave oven operation O p e r ati on T i m e C h ec k in g d o: c he c k s ta tu s O K d o: run C o ok ge ne ra t or T u rn ta b le fa ul t E m i tt e r fa ul t T i m eo ut A l a rm d o: di sp la y ev e nt D o ne d o: bu z z e r on for 5 s e c s. D o or o pe n C a nc e l D i s ab le d Wa it in g