Caratteristiche dei sistemi real-time

Transcript

1 Mod 1 1

2 Mod 1 2

3 Caratteristiche dei sistemi real-time Le caratteristiche più rilevanti da un punto di vista software sono: Prestazioni elevate Il tempo di risposta richiesto ai sistemi real-time è un fattore di notevole criticità: la risoluzione temporale con la quale si debbono susseguire cause ed effetti, è a volte dell ordine delle frazioni di millisecondo. Variabilità del carico di elaborazione L elaborazione eseguita dai sistemi real-time è molto spesso condizionata dal verificarsi di eventi esterni a fronte dei quali devono, in tempi ridotti, intraprendere azioni opportune. Questo comporta una disomogenea distribuzione del carico di elaborazione e il dimensionamento del sistema sulle condizioni di picco. Mod 1 3

4 Caratteristiche dei sistemi real-time Interferenze temporali Eventi significativi possono verificarsi in finestre temporali critiche: per esempio può verificarsi, durante l esecuzione di una routine di risposta ad un evento, un altro evento, magari di natura diversa. Difficoltà di riproduzione del campo in laboratorio Spesso le grandi dimensioni della macchina che dovrà essere controllata dal sistema real-time, o la non disponibilità di alcune sue parti (sovente progetto e sviluppo di software, elettronica e meccanica procedono in parallelo), obbligano ad eseguire il collaudo del software con un impianto ridotto o con un simulatore. La simulazione dei segnali può essere, d altra parte, complessa e di difficile realizzazione soprattutto per quanto riguarda il loro comportamento dinamico. La realizzazione dei simulatori può comportare a volte il progetto e lo sviluppo di sistemi real-time di complessità pari a quella del sistema da collaudare. Mod 1 4

5 Caratteristiche dei sistemi real-time Difficoltà di misura delle prestazioni In molti casi le prestazioni di un sistema real-time sono talmente spinte da rendere oggettivamente difficile la misura dei tempi di risposta effettivi. Robustezza e Affidabilità I sistemi real-time sono usualmente mission critical. Essi debbono quindi spesso fornire un livello minimo di funzionalità anche in condizioni, interne o esterne al sistema, fortemente degradate. Questo implica, a volte, la realizzazione di architetture hw/sw ridondate o comunque con livelli plurimi di funzionalità (funzioni automatiche, semiautomatiche o manuali). Facilità d uso Spesso i sistemi real-time sono embedded in oggetti di uso comune, il che richiede la possibilità di operare in modo fortemente userfriendly. Mod 1 5

6 Caratteristiche dei sistemi real-time Architetture software a processi concorrenti Il software dei sistemi real-time è generalmente costituito da più processi o task eseguiti simultaneamente dal sistema, il quale, a sua volta, può presentare una struttura a processore singolo o multiplo. Nasce quindi l esigenza di coordinare l azione svolta dai singoli processi; a tale scopo vengono usati strumenti di sincronizzazione (interblocco fra processi) e comunicazione (scambio di informazioni fra processi), messi normalmente a disposizione dalle primitive dei sistemi operativi real-time multitasking. D altra parte il progetto, lo sviluppo e il collaudo di architetture a processi concorrenti sono particolarmente difficoltosi anche per la carenza di tool adeguati. Mod 1 6

7 Caratteristiche dei sistemi real-time Prestazioni elevate Variabilità del carico Interferenze temporali Difficoltà di riprod. del campo Architettura a processi concor. Robustezza-Affidabilità Facilità d'uso PROGETTO SVILUPPO COLLAUDO Impatto forte Impatto medio Mod 1 7

8 Sistemi operativi real-time Un buon sistema operativo real-time deve garantire le seguenti funzionalità: Multitasking Schedulazione basata sulla priorità Logica di pre-emption: ovvero possibilità di interruzione di una task da parte di un altra (più prioritaria) Gestione dei sincronismi fra processi (eventualmente anche su processori differenti) Gestione dello scambio dati fra processi (eventualmente anche su processori differenti) Gestione degli interrupt a livello user. In alcuni casi l esigenza di massimizzare le prestazioni obbliga a rinunciare ai vantaggi del supporto di un sistema operativo (situazione frequente per i sistemi embedded). In altri casi l esigenza di aderire a standard commerciali impone l uso di sistemi operativi non real-time per lo sviluppo di applicazioni real-time. Mod 1 8

9 Esempi di sistemi real-time Sistemi di controllo di macchine e impianti industriali Sistemi militari Telefoni cellulari Apparecchi diagnostici e di monitoraggio pazienti Sistemi di prenotazione delle compagnie aeree Sistemi di emissione televisiva Sistemi di visione Sistemi di sicurezza Sistemi di regolazione Elettrodomestici Contatori di energia Sistemi a bordo di aerei, treni, auto Supervisori di reti di gas, acqua, elettricità Casse dei supermercati Monitor ambientali Mod 1 9

10 Mod 1 10

11 Criteri generali di progettazione Il primo criterio di progettazione di un sistema, è quello della Funzionalità ovvero, date le specifiche di funzionamento, ci si preoccupa del fatto che il sistema faccia quanto prescritto. Mod 1 11

12 Criteri generali di progettazione Un progetto real-time sviluppato solo per funzionalità può portare alla realizzazione di un sistema che teoricamente risponde ai requisiti richiesti, ma che, nella realtà, presenta anomalie o limitazioni. E necessario quindi tenere conto di più aspetti, tra i quali sono di notevole importanza le Prestazioni in quanto esiste la necessità di garantire tempi di risposta adeguati rispetto ad eventi asincroni esterni. Mod 1 12

13 Criteri generali di progettazione Tenere in considerazione le prestazioni significa operare innanzitutto opportune scelte di: ARCHITETTURA HW Ad esempio impiego di CPU più veloci, utilizzo di più CPU individuando un fast RT subsystem, ecc. ARCHITETTURA SW Ad esempio non utilizzare SO nel fast RT subsystem, gestire eventi in interrupt piuttosto che in polling, ecc. Un errore frequente è proprio quello di affrontare il problema prestazionale nella fase di tuning del sistema, ovvero quando le scelte HW e SW sono già state fatte. Mod 1 13

14 Criteri generali di progettazione D altra parte il progetto per sole funzionalità e prestazioni può portare alla realizzazione di un oggetto che: si comporta nel modo richiesto solo se sottoposto alle sollecitazioni previste (ovvero risponde bene ai test positivi, ma non altrettanto a quelli negativi); è di scarsa manutenibilità; è difficilmente collaudabile; ecc Queste carenze evidenziano la necessità di altri criteri da rispettare nel progetto di un sistema. Mod 1 14

15 Criteri generali di progettazione MODIFICABILITA /MANUTENIBILITA La manutenzione di un sistema implica costi superiori a quelli di sviluppo (modello iceberg): in fase di progetto o di sviluppo si possono adottare accorgimenti che facilitino le modifiche da apportarsi durante il ciclo di vita del sistema. APPLICAZIONE FUNZIONE A FUNZIONE B FUNZIONE C MODIFICHE Per esempio gli algoritmi di elaborazione associati ad un particolare ciclo lavorativo della macchina sotto controllo dovrebbero essere incapsulati in routines facilmente modificabili o totalmente rimpiazzabili senza necessità di ulteriori modifiche, nel caso in cui cambi il ciclo lavorativo stesso. Mod 1 15

16 Criteri generali di progettazione LEGGIBILITA DEL CODICE Un notevole apporto alla manutenibilità del software è dato dalla chiarezza del codice: rendere il codice leggibile significa fare un uso appropriato di: Commenti Pseudo codice Indentazioni Nomi di costanti e variabili espressivi Documentazione Il codice prodotto non deve essere ad uso esclusivo di chi lo ha sviluppato ma, al contrario, è necessario fornire ad altri specialisti software gli strumenti per acquisirne il dominio, nel più breve tempo possibile (nella new economy il software è un asset aziendale strategico). Mod 1 16

17 Criteri generali di progettazione LEGGIBILITA DEL CODICE La scarsa leggibilità del codice, abbinata ad una cattiva documentazione di progetto, può perfino comportare, nel tempo, la perdita del Know how sugli algoritmi di controllo implementati dal sistema. Mod 1 17

18 Criteri generali di progettazione VALIDABILITA / VERIFICABILITA Identifica il livello di collaudabilità funzionale (esterna) e topologica (interna) del sistema. Quanto più un sistema è modificabile (quindi strutturato e modulare) e leggibile, tanto più esso è verificabile. Mod 1 18

19 Criteri generali di progettazione ROBUSTEZZA Il sistema deve superare bene sia i test positivi, sia quelli negativi: TEST POSITIVI TEST NEGATIVI SISTEMA FUNZIONA E ROBUSTO E quindi necessario prevedere nel codice una buona copertura delle possibili sollecitazioni esterne anomale. L esecuzione dei test negativi è a volte resa ardua dalla difficoltà incontrata nel riprodurre in laboratorio (in house testing) le svariate dinamiche dei segnali esterni. L esigenza di robustezza può quindi portare anche a modificare le scelte di progetto dei simulatori. Mod 1 19

20 Criteri generali di progettazione FACILITA D USO L interazione di un sistema real-time con l utente finale deve spesso essere estremamente agevole, perché l operatore può avere un basso livello di specializzazione professionale o essere impegnato in attività manuali, oppure perché il sistema è embedded in oggetti di uso comune. Nasce quindi l esigenza di realizzare interfacce uomo-macchina che garantiscano la maggior ergonomicità e che siano il più possibile userfriendly, operando scelte che coinvolgono tanto l operatività (ad esempio numero di tasti e loro dislocazione) quanto la gestione software. In taluni casi è anche opportuno prevedere più livelli di utente: system administrator, super-user, user. Mod 1 20

21 Criteri generali di progettazione PORTABILITA Equivale a salvaguardare l investimento software rispetto all evoluzione tecnologica (non solo SO, ma anche I/O, reti, ecc.) e funzionale: allungando quindi il ciclo di vita del prodotto software. APPLICAZIONE IN C INTERFACCIA INTERFACCIA S. O. #1 S. O. #2 Mod 1 21

22 Criteri generali di progettazione SEMPLICITA /ELEGANZA ARCHITETTURALE Un sistema elegante è semplice; se il sistema non è semplice creerà più problemi del necessario. PUNTATORE 3000 A100 10FF 10FF FUNZIONE A100 A VETTORE DI PUNTATORI A200 AF00 Era necessario? A200 AF00 FUNZIONE B FUNZIONE n Fai le cose nel modo più semplice possibile, ma non più semplice (A. Einstein) Mod 1 22

23 Criteri generali di progettazione I criteri esaminati sono normalmente in conflitto fra loro: Un sistema altamente portabile sarà poco prestazionale (le interfacce software rallentano l esecuzione). D altra parte non è sempre richiesto il pieno rispetto di tutti i criteri visti: La manutenibilità è quasi sempre strategica, ma non per un SW che serve per un esperimento e poi viene abbandonato (ad esempio un simulatore). Mod 1 23

24 Criteri generali di progettazione MODIFICABILITA ROBUSTEZZA FACILITA D USO FUNZIONALITA MODELLO DEL SISTEMA PRESTAZIONI PORTABILITA LEGGIBILITA SEMPLICITA Si affina il modello osservandolo da più punti di vista... Mod 1 24

25 Criteri generali di progettazione quando il modello sarà armoniosamente accordato rispetto a tutti i fattori rilevanti per lo specifico progetto, il sistema avrà preso corpo. Allora si potrà ridurre il livello di astrazione (procedendo top-down) e ricominciare da capo il processo. Mod 1 25

26 Mod 1 26

27 Principi dell OOD L OOD è una filosofia di progettazione dei sistemi risultante da una decennale evoluzione storica della cultura del SW design. Mod 1 27

28 Principi dell OOD DEFINIZIONE Un progetto orientato agli oggetti è basato su entità (oggetti) che hanno uno stato e operazioni su di esso, che non risultano visibili dall esterno (information hiding). Il progetto è espresso in termini di servizi richiesti e forniti da oggetti interagenti. Le principali caratteristiche del progetto sono: la eliminazione di aree dati condivise (le interazioni avvengono per scambio di messaggi); gli oggetti sono entità indipendenti (incapsulate), facilmente modificabili a condizione di mantenerne le interfacce; gli oggetti possono essere distribuiti e possono eseguire le elaborazioni sequenzialmente o in parallelo. Mod 1 28

29 Principi dell OOD La definizione precedente evidenzia che l OOD impiega nel SW design principi generali di organizzazione dei processi industriali. Mod 1 29

30 Principi dell OOD DEFINIZIONE Un progetto orientato agli oggetti è basato su entità (oggetti) che hanno uno stato e operazioni su di esso, che non risultano visibili dall esterno (information hiding). Il progetto è espresso in termini di servizi richiesti e forniti da oggetti interagenti. Le principali caratteristiche del progetto sono: la eliminazione di aree dati condivise (le interazioni avvengono per scambio di messaggi); gli oggetti sono entità indipendenti (incapsulate), facilmente modificabili a condizione di mantenerne le interfacce; gli oggetti possono essere distribuiti e possono eseguire le elaborazioni sequenzialmente o in parallelo. Su questo principio si basano sia il packaging dei circuiti integrati nella produzione di componenti elettronici, sia il modello ISO-OSI nella progettazione di reti di comunicazione dati. Mod 1 30

31 Principi dell OOD DEFINIZIONE Un progetto orientato agli oggetti è basato su entità (oggetti) che hanno uno stato e operazioni su di esso, che non risultano visibili dall esterno (information hiding). Il progetto è espresso in termini di servizi richiesti e forniti da oggetti interagenti. Le principali caratteristiche del progetto sono: la eliminazione di aree dati condivise (le interazioni avvengono per scambio di messaggi); gli oggetti sono entità indipendenti (incapsulate), facilmente modificabili a condizione di mantenerne le interfacce; gli oggetti possono essere distribuiti e possono eseguire le elaborazioni sequenzialmente o in parallelo. Questo è il principio generale di standardizzazione dei componenti su cui si basa la maggioranza degli interventi di razionalizzazione dei processi produttivi Mod 1 31

32 Principi dell OOD DEFINIZIONE Un progetto orientato agli oggetti è basato su entità (oggetti) che hanno uno stato e operazioni su di esso, che non risultano visibili dall esterno (information hiding). Il progetto è espresso in termini di servizi richiesti e forniti da oggetti interagenti. Le principali caratteristiche del progetto sono: la eliminazione di aree dati condivise (le interazioni avvengono per scambio di messaggi); gli oggetti sono entità indipendenti (incapsulate), facilmente modificabili a condizione di mantenerne le interfacce; gli oggetti possono essere distribuiti e possono eseguire le elaborazioni sequenzialmente o in parallelo. Questi principi sono di normale utilizzo nella progettazione delle strutture organizzate. Mod 1 32

33 Principi dell OOD DEFINIZIONE Un progetto orientato agli oggetti è basato su entità (oggetti) che hanno uno stato e operazioni su di esso, che non risultano visibili dall esterno (information hiding). Il progetto è espresso in termini di servizi richiesti e forniti da oggetti interagenti. Le principali caratteristiche del progetto sono: la eliminazione di aree dati condivise (le interazioni avvengono per scambio di messaggi); gli oggetti sono entità indipendenti (incapsulate), facilmente modificabili a condizione di mantenerne le interfacce; gli oggetti possono essere distribuiti e possono eseguire le elaborazioni sequenzialmente o in parallelo. Ecc., Ecc., Ecc. L OOD è figlio naturale della cultura industriale. Mod 1 33

34 Principi dell OOD - Evoluzione storica Linguaggio macchina (operandi/operatori) C++ -VisualStudio Assembler Smaltalk - Ada Linguaggi di terza generazione Astrazione-Information hiding - Inheritance Programmazione modulare Librerie Mod 1 34

35 Principi dell OOD La metafora dei SW IC s Gli oggetti equivalgono metaforicamente ai circuiti integrati (IC s) usati nella ingegneria HW. Gli IC s a grande integrazione (VLSI) hanno prodotto una formidabile accelerazione nel progresso della progettazione circuitale. La non fisicità del software consente di potenziare l approccio attraverso meccanismi impossibili nel mondo fisico: istanza dinamica degli oggetti inheritance. Mod 1 35

36 Principi dell OOD OOD e progettazione di sistemi real-time Le architetture software dei sistemi real-time sono state storicamente progettate strutturando il sistema in più task concorrenti (sovente gestori di fenomeni fisici) che scambiano dati e sincronizzazioni mediante un area dati condivisa. TASK A DB Memory Resident TASK B Mod 1 36

37 Principi dell OOD OOD e progettazione di sistemi real-time Quindi l impiego di alcuni principi dell ODD, in particolare quello di architettare il software mediante oggetti concorrenti che svolgono servizi su evento (notificato mediante l inoltro di messaggi), fa parte della tradizione storica della progettazione real-time. Tuttavia l esigenza di tempi di risposta all evento ridotti, combinata spesso alla disponibilità di potenze di elaborazione limitate (si pensi ai microcontrollori usati nelle applicazioni embedded), ha indotto, e induce in molti casi tuttora, a sostituire lo scambio di messaggi con interazioni implicite in aree di memoria condivise, contraddicendo, almeno dal punto di vista realizzativo se non dal punto di vista concettuale, il principio focale dell OOD, ovvero l information hiding. Mod 1 37

38 Principi dell OOD OOD e progettazione di sistemi real-time La crescente potenza di elaborazione disponibile anche per alcune applicazioni embedded (ad esempio i telefoni cellulari) crea le premesse per un impiego molto più ampio dell OOD e dell OOP nella progettazione di sistemi real- time. Questo consentirà molto presto il superamento della tradizionale frattura fra disegno logico e disegno fisico dei sistemi real-time. Mod 1 38

39 Principi dell OOD OOD e OOP Va notato, per inciso, che la progettazione OOD e la programmazione OOP, non necessariamente debbono essere coniugate. Ovvero è possibile realizzare un sistema progettato con approccio OOD, ma non sviluppato con linguaggi di programmazione ad oggetti (quindi senza supporto da parte del linguaggio di oggetti e meccanismi associati, come l inheritance). Questo può essere un ragionevole compromesso per la progettazione di sistemi che debbono operare su piattaforme di potenza e capacità limitate. Mod 1 39

40 Classe Principi dell OOD Alcune definizioni Identifica un insieme di oggetti che condividono gli stessi attributi, operazioni, metodi, relazioni e comportamenti. Essa rappresenta un concetto nel sistema da modellare. Oggetto Una entità discreta con confini ben precisi che incapsula stato e comportamento: è un istanza di una classe. Gli oggetti possono essere passivi (i cambiamenti di stato derivano da operazioni indotte dall arrivo di messaggi dall esterno) oppure attivi (capaci di cambiare stato anche in funzione di operazioni eseguite internamente - non sollecitate dall esterno). Mod 1 40

41 Principi dell OOD Alcune definizioni Messaggio Il passaggio di informazione da un oggetto ad un altro, con l aspettativa che venga eseguita un attività. Ereditarietà Il meccanismo attraverso il quale elementi più specifici incorporano struttura e comportamenti definiti da elementi più generali. L ereditarietà multipla indica la possibilità di ereditare attributi da più di un elemento più generale. Mod 1 41

42 Principi dell OOD Vantaggi dell ODD I principali vantaggi sono: Facilità di manutenzione: un cambiamento della implementazione di un oggetto o l aggiunta di servizi, non provocano alcun impatto sugli altri oggetti del sistema. Riusabilità dei componenti: l indipendenza degli oggetti consente il loro riutilizzo in nuovi progetti. Affidabilità: l information hiding permette di eliminare bugs subdoli dovuti a modifiche indesiderate alle strutture dati. Mod 1 42

43 Principi dell OOD Identificazione degli oggetti Uno dei problemi di maggior complessità e importanza nell OOD è la accurata ed efficace identificazione degli oggetti: identificazione degli oggetti e dei loro attributi; identificazione delle operazioni che possono essere applicate agli oggetti; definizione delle interfacce mediante la identificazione delle relazioni fra oggetti e operazioni. Mod 1 43

44 Principi dell OOD Identificazione degli oggetti Secondo Booch un approccio molto semplice per la soluzione di questo problema consiste nello stendere una sintetica descrizione del problema ed evidenziare nel testo i nomi comuni (normalmente indicatori di classi: ad esempio veicolo ) e i nomi propri (normalmente indicatori di oggetti: ad esempio Ferrari Testa Rossa ). Il testo deve essere scritto: in linguaggio semplice, mantenendo sempre lo stesso livello di astrazione, focalizzandosi su cosa deve essere fatto e non su come deve essere fatto, eliminando i dettagli superflui, usando ripetitivamente gli stessi termini, evitando i sinonimi. Mod 1 44

45 Principi dell OOD Identificazione degli oggetti Vediamo un esempio. Un computer centrale trasmette blocchi NC a un controllo numerico che contiene un software che legge ciascun blocconc e lo memorizza in un NC program file. I blocchi NC sono letti dal NC program file e decomposti in istruzioni per funzioni di posizionamento e speciali. Le istruzioni sono processate e codificate in comandi di controllo di posizione e comandi speciali che sono inviati agli azionamenti della macchina. I comandi dell Operatore sono inviati al software NC attraverso una interfaccia a tastiera. I comandi dell Operatore consentono all Operatore di inserire un blocco NC in un NC program file esistente, di presentare un NC program file su CRT e di eseguire un NC program. Mod 1 45

46 Principi dell OOD Identificazione degli oggetti Vediamo un esempio. Un computer centrale trasmette blocchi NC a un controllo numerico che contiene un software che legge ciascun blocconc e lo memorizza in un NC program file. I blocchi NC sono letti dal NC program file e decomposti in istruzioni per funzioni di posizionamento e speciali. Le istruzioni sono processate e codificate in comandi di controllo di posizione e comandi speciali che sono inviati agli azionamenti della macchina. I comandi dell Operatore sono inviati al software NC attraverso una interfaccia a tastiera. I comandi dell Operatore consentono all Operatore di inserire un blocco NC in un NC program file esistente, di presentare un NC program file su CRT e di eseguire un NC program. Mod 1 46

47 Principi dell OOD Identificazione degli oggetti L esempio consente di definire la seguente tabella di oggetti. Oggetto Dominio Commento Computer centrale P Blocco NC S Controllo numerico P Software S Per NC NC program file S Composto di blocchi NC Istruzioni S Per funzioni di posizionamento e speciali Funzioni P Attività eseguite dagli azionamenti Comandi di controllo posizione S Comandi speciali S Azionamenti della macchina P Comandi Operatore S Interfaccia a tastiera S Operatore P CRT P NC program S Sinonimo di NC program file P: dominio del problema (oggetti esterni al SW del controllo numerico) S: dominio della soluzione (oggetti direttamente creati/gestiti dal SW del controllo Mod 1 numerico) 47

48 Principi dell OOD Identificazione degli oggetti Considerando solo gli oggetti pertinenti al dominio S ed esaminando le operazioni associate ai nomi nel testo, possiamo infine definire la seguente tabella di oggetti e relative operazioni. Oggetto Blocco NC NC program file Istruzioni Comandi di controllo posizione Comandi speciali Comandi Operatore Operazioni Leggi dal computer centrale Leggi dall'nc program file Inserisci in un NC program file esistente Memorizza Carica Presenta su CRT Esegui Processa Codifica Manda agli azionamenti Manda agli azionamenti Inserisci da tastiera Mod 1 48

49 Mod 1 49

50 Mod 1 50

51 Cosa è UML? UML è un linguaggio di modellazione visuale general-purpose. UML è un linguaggio di modellazione e non una metodologia di sviluppo, esso non impone alcuna regola relativamente al processo di sviluppo adottato. UML è quindi inteso per l impiego con tutte le metodologie di sviluppo, in tutti le fasi di progetto, in tutti i domini applicativi della progettazione di sistemi discreti (no sistemi continui), per tutte le piattaforme di sistema target, con tutti gli strumenti di supporto. Uno dei propositi fondamentali dell UML è quello di fornire una sintassi grafica standard che serva come ampia base per lo sviluppo di strumenti di progettazione assistita da calcolatore. Mod 1 51

52 Cosa è UML? E importante ribadire che UML e il processo di sviluppo che usa UML sono due cose distinte. Scelto UML è quindi necessario definire il processo che lo supporta. Mod 1 52

53 Mod 1 53

54 Quale è lo scopo di un modello? Un modello consente: di definire con precisione i requisiti di sistema, di sperimentare varie soluzioni con costi contenuti, di mantenere sotto controllo la complessità dell attività di progettazione, di esaminare una soluzione di progetto da più punti di vista (strutturale, dinamico, ecc.), di trasmettere agevolmente a più persone con competenze diverse la conoscenza sul sistema progettato (documentazione grafica), di simulare con un calcolatore il comportamento del sistema da sviluppare. Mod 1 54

55 Mod 1 55

56 Genesi di UML UML è il risultato di uno sforzo di unificazione di tutti i precedenti linguaggi per la modellazione di sistemi realizzati con OOD. Mod 1 56

57 Genesi di UML Nel 1994 Rumbaugh si unisce a Booch in Rational Software Corp. Essi cominciano a combinare i concetti dell OMT (Rumbaugh) con il metodo di Booch. Nel 1995 anche Jacobson entra in Rational Software Corp., il che porta ad uno sforzo congiunto dei tre principali metodologi del momento. Vengono quindi sviluppate le prime proposte di UML. Nel 1996 l Object Management Group (OMG) lancia il progetto di un approccio standard alla modellazione object-oriented. Un gruppo di lavoro che include i tre metodologi di Rational ed altri specialisti di altre società lavora insieme per proporre un linguaggio standard a costruttori di tool e sviluppatori di SW. La versione di UML predisposta dal gruppo diviene uno standard OMG nel Novembre Mod 1 57

58 Genesi di UML Lo scopo dello standard OMG è quello di favorire un ampio uso della modellazione OO fra i progettisti SW e di promuovere un mercato robusto di strumenti di progettazione assistita e di formazione, facendo sì che né gli utenti, né i produttori debbano più interrogarsi su quale approccio usare e supportare. Mod 1 58

59 Mod 1 59

60 Classifier Ulteriori definizioni Un elemento del modello che descrive caratteristiche comportamentali e strutturali (classi, ma anche componenti, interfacce, sottosistemi). Message La trasmissione di informazione da un oggetto ad un altro, per richiedere la esecuzione di attività. Può essere una signal (richiesta asincrona) o la chiamata di una operazione (richiesta sincrona). Il ricevimento di un message equivale all istanza di un evento. Mod 1 60

61 Ulteriori definizioni Method E la implementazione di un operazione (un comportamento di una classe). Specifica l algoritmo che produce il risultato di un operazione. Signal E una comunicazione asincrona fra oggetti. Le signal possono avere parametri espressi come attributi. Mod 1 61

62 Mod 1 62

63 La struttura di UML Dominio View Strutturale Use Case View Static View Phisical View Dinamico State machine View Activity View Interaction View Model Management Model management View Mod 1 63

64 La struttura di UML L impiego di View diverse consente di definire aspetti diversi del comportamento di un sistema (in sintesi offre punti di vista diversi del sistema) Mod 1 64

65 Use case View La struttura di UML Dominio strutturale Rappresenta il comportamento del sistema visto dall esterno (utenti o altri sistemi). Static View E la vista fondamentale; rappresenta la struttura degli oggetti. Si occupa di tutte le problematiche relative alle strutture dati e alle operazioni eseguite su di essi. Gli elementi chiave della vista sono i classifier e le loro relazioni. Phisical View Rappresenta la struttura fisica (implementativa) del sistema. Mod 1 65

66 State machine View La struttura di UML Dominio Dinamico Rappresenta il comportamento dinamico degli oggetti, mediante la modellazione del ciclo di vita degli oggetti di ciascuna classe. Activity View E la vista che modella le elaborazioni e i flussi dati, mediante pseudo reti di Petri. Interaction View Rappresenta le modalità di interazione fra oggetti. Mod 1 66

67 La struttura di UML Dominio di Model Management Model management View Divide il modello in sotto-modelli che possono essere realizzati da gruppi di lavoro diversi. Identifica quindi i package e le relazioni fra essi. Mod 1 67

68 La struttura di UML Sinottico dei formalismi grafici (diagrammi) Dominio View Formalismi grafici Strutturale Use Case View Use case Diagram Static View Class Diagram Physical View Component Diagram/Deployment Diagram Dinamico State machine View Statechart Diagram Activity View Activity Diagram Interaction View Sequence Diagram/Collaboration Diagram Model Management Model management View Class Diagram Mod 1 68

69 Mod 1 69

70 Use Case View Mostra il comportamento di un sistema, di un sottosistema o di una classe come appare dal mondo esterno Evidenzia le interazioni fra attori (utenti o sistemi esterni) e pezzi di funzionalità interattive denominate use case Ogni attore può partecipare a più use case, scambiando messaggi con essi La finalità degli use case è la identificazione dei requisiti funzionali di sistema Mod 1 70

71 Use case Diagram Allarmistica/Supervisione Manutenzione <<extend> Gestione dati di manutenzione Mgmt della manutenzione Ingegneria Sistema di raccolta dati di stabilimento Gestione dati analitici di produzione Produzione Gestione dati analitici di Controllo Qualità (scarti) CQ Gestione dati di misura su pezzi prodotti e carte di qualità Clienti ABB Mod 1 Presentazione dati sintetici sullo 71 stabilimento Top Mgmt

72 Use Case View Tipi di relazioni fra use case Relazione Funzione Notazione Associazione Estensione Generalizzazione del use case Inclusione La linea di comunicazione tra un attore e un use case che partecipa ad essa L inserimento di funzioni aggiuntive in un use case base, che non è consapevole di esse Una relazione fra un use case generale e uno più specifico che eredita e aggiunge funzioni ad esso L inserimento di funzioni aggiuntive in un use case base, che è consapevole di esse <<extend>> <<include>> Mod 1 72

73 Use Case View Tipi di relazioni fra use case Nome del sistema Use case Comunicazione tra attori use case Vendita telefonica Controlla lo stato Piazza l ordine Attore Venditore Cliente Nome use case Esegue l ordine Stabilisce il credito Addetto alla spedizione Confine di sistema Supervisore Mod 1 73

74 Use Case View Esempio di relazione fra use case Use case base Piazza l ordine <<extend>> Richiede catalogo <<include>> <<include>> <<include>> Estensione use case Inserisce dati del cliente Ordina il prodotto Stabilisce il pagamento Use case padre Use case inclusi Paga in contanti Accorda un credito Use case figlio Mod 1 74

75 Mod 1 75

76 Static View E il fondamento dell UML. La dynamic view la presuppone, in quanto non è possibile descrivere come qualcosa interagisce, se non si è prima definito cosa deve interagire Definisce la struttura degli oggetti Copre tutte le problematiche associate alle strutture dati e alle operazioni eseguite su esse Mod 1 76

77 Static View Gli elementi chiave della static view sono i classifier e le loro relazioni Mod 1 77

78 Static View Tipi di classifier Classificatore Funzione Notazione Attore Un utente esterno del sistema Classe Classe in stato Un concetto nel sistema modellato Una classe in un certo stato Nome Nome(S) Ruolo di un classificatore Un classifier in un certo ruolo Role:Nome Componente Un pezzo fisico del sistema Mod 1 78

79 Static View Tipi di classifier Classificatore Funzione Notazione Interfaccia Nodo Un insieme di operazioni Una risorsa di elaborazione I-nome Segnale Comunicazione asincrona fra oggetti <<signal>> Sottosistema Un package implementativo <<subsystem>> Use case Una funzionalità di una entità Mod 1 79

80 Static View Notazione grafica di una classe Abbonamento Serie: Stringa Categoria-di-prezzo: Categoria Numero: Intero Acquista() Prenota(Serie, Livello di posto) Cancella() Nome di classe Attributi Operazioni Mod 1 80

81 Static View Tipi di relazioni fra classifier Relazione Funzione Notazione Associazione Connessione fra istanze di classi Dipendenza Dipendenza consumatore/fornitore Flusso Flusso fra due stati diversi di un oggetto in due istanti diversi Mod 1 81

82 Static View Tipi di relazioni fra classifier Relazione Funzione Notazione Generalizzazione Relazione figlio-padre Realizzazione Relazione specifica-implementazione Utilizzo Un oggetto richiede un altro per il suo corretto funzionamento Mod 1 82

83 Static View Associazione Successivo Classe di allarme 1..n Precedente (ruolo) Priorità (nome dell associazione) * Allarme Priorità (auto-associazione) Mod 1 83

84 Static View Classe di associazione Reparto 1..n * Linee di produzione Prodotto annuo Pezzi prodotti: intero Pezzi scartati: intero (attributi dell associazione) Serve per fornire attributi ad una associazione Mod 1 84

85 Static View Qualificatore di una associazione (Qualificatore) Sensore Data evento: data orario evento: orario Evento (Attributi del qualificatore) Serve per identificare un unico oggetto in un insieme di oggetti correlati da una associazione Mod 1 85

86 Static View Aggregazione Abbonamento Aggregato * * Performance Parti E una associazione che aggrega le parti ad un tutto Mod 1 86

87 Static View Composizione Composto Ordine * Parti Dati del cliente Linea d ordine E una forma di associazione più forte nella quale il composto gestisce le parti (i.e. le alloca/dealloca) Mod 1 87

88 Static View Generalizzazione Evento Data Evento: Data Acknowledge () Super classe (padre) Allarme Tipo Procedura: Intero Esegui Procedura () Guasto Codice Impianto: Intero Richiesta Manutenzione () Sottoclasse (figlio) Mod 1 88

89 Static View Generalizzazione E una relazione tassonomica fra una descrizione più generale e una più specifica che è costruita su di essa e la estende Permette la descrizione incrementale di un elemento mediante condivisione delle descrizioni dei predecessori (ereditarietà, eventualmente multipla) Mod 1 89

90 Static View Realizzazione <<Interface>> Blocco di scelta setdefault (scelta:scelta) getchoice():scelta Scelta 1..* scelta Relazione di realizzazione specifica Vettore di Radio Button setdefault (scelta:bottone) getchoice():bottone 1..* scelta implementazione PopUpMenu setdefault (scelta:bottone) getchoice():bottone scelta 1..* Stringa Bottone Mod 1 90

91 Static View Realizzazione Sia la generalizzazione sia la realizzazione correlano una descrizione più generale ad una più dettagliata; la generalizzazione correla elementi allo stesso livello semantico, la realizzazione a diversi livelli semantici. Mod 1 91

92 Static View Dipendenze Esistono vari altri tipi di relazioni di dipendenza, normalmente caratterizzati da Keyword: call friend instantiate use Mod 1 92

93 Static View Vincoli Persona Membro di * * sottoinsieme 1 * Presidente di costrizione tra associazioni Comitato Un vincolo è espresso da un testo fra parentesi graffe. Mod 1 93

94 Static View Conclusione Un modello è la descrizione di una potenzialità, del possibile insieme di oggetti che possono esistere e del possibile insieme di comportamenti attraverso i quali essi possono evolvere. La static view definisce e vincola le possibili configurazioni statiche del modello (snapshot). La dynamic view definisce come il modello può evolvere da uno snapshot ad un altro. Mod 1 94

95 Mod 1 95

96 State machine View La state machine view descrive il comportamento dinamico di oggetti nel tempo, modellando il ciclo di vita degli oggetti di ciascuna classe Qualunque cosa che influenzi un oggetto è caratterizzata come un evento Le macchine a stati descrivono il comportamento dinamico di oggetti, ma anche di use case, collaborazioni e metodi Una macchina a stati è un grafo di stati e transizioni Mod 1 96

97 State machine View Eventi Gli eventi non hanno durata Gli eventi possono avere parametri che caratterizzano ciascuna loro istanza Mod 1 97

98 State machine View Tipi di eventi Tipo di evento Descrizione Sintassi Evento di chiamata Evento di cambiamento Richiesta sincrona da un oggetto che attende risposta Un cambiamento nel valore di una espressione booleana op (a:t) when (exp) Signal Richiesta asincrona da un oggetto sname (a:t) Evento a tempo Evento a tempo assoluto o relativo after (tempo) Mod 1 98

99 State machine View Eventi <<signal>> InputEvent tempo Segnale astratto <<signal>> UserInput device <<signal>> Tasto del Mouse locazione <<signal>> Carattere della Tastiera carattere Un evento può essere descritto da un class diagram Mod 1 99

100 State machine View Transizioni Definiscono la risposta dell oggetto, in uno stato, all occorrenza di un evento In generale sono caratterizzate da un evento scatenante, una guard condition, un azione e uno stato target La guard condition è una espressione che condiziona il firing di una transizione, essa è quindi valutata quando si presenta l evento scatenante (da non confondersi con evento di cambiamento che è valutato continuamente) Mod 1 100

101 Tipo di transazione Azioni in entrata State machine View Tipi di transizioni Descrizione Normalmente azioni di set-up Sintassi entry/azione Azioni in uscita Normalmente azioni di clean-up exit/azione Transizione esterna Azione associata a una transizione di stato e (a:t) exp /azione Transizione interna Risposta ad un evento che non produce una transizione di stato e (a:t) exp /azione Mod 1 101

102 State machine View Esempio di state machine semplice Riceve ordine Importo>$25 Attesa Riceve ordine Importo>$25 Evento Guard Condition Conferma Credito rifiutato Transizione Approvato/addebito-conto() Evento/Azione Esegui Ordine Cancella Ordine Mod 1 102

103 State machine View Tipi particolari di transizioni Completion transition: non ha un evento scatenante esplicito, si verifica al completamento dell attività nello stato lasciato Internal transition: manca di stato target, perché non implica l abbandono dello stato corrente (ad esempio entry per le operazioni di set-up e exit per quelle di clean-up) Self-transition: in questo caso lo stato target è quello corrente, ma la transizione esterna avviene e quindi si attivano i meccanismi di exit/entry Mod 1 103

104 State machine View Esempio di stato con internal transition nome Immetti Password azioni di entrata e uscita transizioni interne entry/set echo to star;password.reset() exit/set echo normal digit/handle character clear/password.reset() help/display help Mod 1 104

105 State machine View Stati composti Sono uno degli elementi più innovativi del formalismo UML, rispetto al formalismo classico degli automi a stati di Mealy Uno stato composto può essere decomposto in sottostati sequenziali o concorrenti Mod 1 105

106 State machine View Tipi di stati Tipo di stato Descrizione Notazione Stato semplice Stato con nessuna sottostruttura Stato composto concorrente E composto da più sottostati che risultano simultaneamente attivi, quando lo stato composto è attivo Stato composto sequenziale E composto da più sottostati, uno solo dei quali è attivo, quando lo stato composto è attivo Stato iniziale Pseudostato che indica lo stato iniziale per lo stato che lo contiene Mod 1 106

107 State machine View Tipi di stati Tipo di stato Descrizione Sintassi Stato finale La sua attivazione indica che lo stato che lo contiene ha terminato l attività Stato di giunzione Stato storico Referenza a sottomacchina Pseudostato usato per collegare le frecce di transizione Permette di tornare allo stato precedente, se si rientra in uno stato composto Indica una intera sotto-macchina a stati da includere nell automa H Include S Stato Stub Usato per ingressi e uscite da referenze a sottomacchine Mod T

108 Idle Inserim. carta State machine View Esempio di state machine con stato composto Transazione completata Acquisto Exit/espulsione carta Stato iniziale Transizione interna Referenza sottomacchina Include Identificazione fallisce Uscita forzata Uscita normale /reset selezione Seleziona Prende(posto) / aggiunge alla selezione(posto) Stato finale Una transizione esterna annulla un attività interna Tasto cancella Azione atomica Tasto resume Conferma Tasto compra Tasto conferma Transazione Vende completata Entry/vende() Mod 1 108

109 State machine View Regole per la gestione di stati composti La transizione dentro o fuori da uno stato composto implica l esecuzione di azioni di entry o exit. Se ci sono molti stati composti (nesting multiplo), la transizione attraverso vari livelli implica azioni multiple di entry (prima la più esterna) o di exit (prima la più interna) Una transizione sul confine di uno stato composto è implicitamente una transizione al suo stato iniziale Una transizione allo stato finale attiva una completion transition per uno stato composto Mod 1 109

110 State machine View Esempio di state machine con stato composto concorrente Acquisizione misure Entry/inizializza ADC e timer di campionamento Attesa Fine DT Elaborazione misura Entry/reinizializza timer Confronto soglia normale allarme Notifica allarme Aggiornamento log misure Mod 1 110

111 Mod 1 111

112 Activity View Un activity graph è una forma speciale di macchina a stati impiegata per modellare elaborazioni e flussi di lavoro Strutturalmente è simile a una rete di Petri o a un SFC (IEC 61131) Un activity graph è simile a un flow-chart tradizionale a parte che consente un controllo concorrente oltre al controllo sequenziale: questa è una differenza notevole Mod 1 112

113 BoxOffice::ElaboraOrdine Activity View Esempio di activity diagram branch abbonamento Inizial. ordine Guard condition Ordine singolo barra (biforcazione) Assegna posti Assegna posti Thread concorrenti Addebito conto Merge (unbranch) Assegna bonus barra (associazione) Vie alternative Addeb. carta di credito Invio Mod 1 biglietti 113

114 Activity View Esempio di activity diagram con corsie Cliente Venditore Magazzino Richiesta servizio Paga Ordine consegnato Ordine piazzato Prende l ordine Ordine inserito Consegna l ordine Ordine entrato Inserisce l ordine Raccolta ordine Le corsie (swimlanes) sono usate per raggruppare le attività per unità organizzativa, risorsa di elaborazione, layer di architettura, ecc. Mod 1 114

115 Activity View L activity graph è un punto iniziale del design Le attività debbono essere espanse in una o più operazioni, che debbono essere attribuite a particolari classi che debbono implementarle Tale assegnazione implica il progetto di collaborazioni (rappresentate da collaboration diagram) che implementano la sequenza evidenziata dall activity graph Mod 1 115

116 Mod 1 116

117 Interaction View Gli oggetti interagiscono fra loro per implementare un comportamento Una macchina a stati è una specifica precisa che consente agevolmente la generazione del codice Una macchina a stati è però un formalismo che può rendere ardua la comprensione delle interazioni fra oggetti; questa problematica è modellata dalle collaborazioni Mod 1 117

118 Interaction View Collaborazioni Una collaborazione è la descrizione di un insieme di oggetti che interagiscono per implementare un certo comportamento in un certo contesto Una collaborazione si compone di classifier role (classifier che svolgono un certo ruolo nello scenario) e association role (link che contribuiscono alla esecuzione della collaborazione) Un oggetto può partecipare a più di una collaborazione (scenari, contesti) Le collaborazioni evidenziano strutture dati, flussi di controllo e flussi dati Mod 1 118

119 Interaction View Interazioni Una interazione è un insieme di messaggi entro una collaborazione che sono scambiati da classifier role attraverso association role Un messaggio può essere una signal (comunicazione asincrona) o una call (chiamata sincrona con un meccanismo di ritorno del controllo al mittente) La sequenzializzazione di messaggi può essere rappresentata da due tipi di diagrammi: Sequence diagram : focalizzati sulla sequenza temporale dei messaggi Collaboration diagram: focalizzati sulla interrelazione fra oggetti che scambiano messaggi Mod 1 119

120 Attore esterno Interaction View Sequence Diagram Oggetto attivo :Chiosco :Server :Servizio Credito Carta inserita (cliente) Data scelta(data) Offerta (posti disp.) Selezione (posti) Stampa (ordine) Messaggio sottomissione (ordine) OK Addebito (cliente, importo) Autorizza Lifeline(attivo) Il tempo evolve dall alto verso il basso Mod 1 120

121 Interaction View Collaboration Diagram Richiedente Richiesta (ordine, cliente) Flusso dei messaggi :Collezione ordini 2:costo:=prenota(ordine) Ruolo del classifier :BigliettiDB 1:Controllo-credito(cliente) 3:addebito(cliente,costo) Numero di sequenza :Ufficio Crediti Navigazione one-way In questo caso la sequenza è rappresentata dal numero progressivo Mod 1 121

122 Interaction View Aree di impiego Un Sequence diagram è usato prevalentemente per descrivere scenari (sequenze di collaudo, transazioni, ecc.) Un Collaboration diagram è più utile nella progettazione di dettaglio, ad esempio delle interfacce. Si ricordi però che una collaborazione è circoscritta a un contesto e quindi il progetto è completo solo quando si è analizzato l insieme di tutti i possibili contesti. Mod 1 122

123 Interaction View Pattern E una collaborazione parametrizzata che rappresenta un insieme di classifier, relazioni e comportamenti parametrici. E un template di collaborazione astratto e riusabile, mediante attribuzione di classi del modello ai ruoli del pattern. In sostanza è una forte astrazione, un modello concettuale riusabile Mod 1 123

124 Sensore analogico Interaction View Pattern Trend Sorgente dati Oggetto HMI Presentazione misure La misura può essere presentata con più oggetti grafici che evidenziano il valore istantaneo o la sua evoluzione Nel pattern Presentazione misure si ha Sensore analogico nel ruolo di Sorgente dati e Trend nel ruolo di Oggetto HMI Mod 1 124

125 Mod 1 125

126 Physical View La Physical view descrive la struttura implementativa del sistema Essa evidenzia i componenti con cui si vuole realizzare il sistema E una view importante perché i componenti sono i pezzi riusabili con cui i sistemi possono essere costruiti; un buon repositorio di componenti è quindi un asset aziendale strategico Essa include una descrizione dei componenti (e delle relative interfacce), delle relazioni fra componenti e della dislocazione dei componenti sui nodi di elaborazione Mod 1 126

127 Physical View Componente ed interfacce esposte Componente Dizionario Spell-check Sinonimi interfacce Mod 1 127

128 Physical View Component Diagram <<database>> Conto Componente stereotipato Transazioni Aggiornamento interfaccia Componente Dipendenza di realizzazione ATM-GUI Dipendenza d uso Mod 1 128

129 Physical View Deployment diagram Istanza di componente Istanza di nodo server:bankserver :Transazioni Linea di comunicazione client:atmkiosk <<database>> contodb: Conto aggiornamento :ATM-GUI dipendenza Interfaccia Mod 1 129

130 Mod 1 130

131 Model management View Qualunque grande sistema deve essere diviso in unità più piccole in modo che le persone possano lavorare in ogni istante con una limitato ammontare di informazioni, rendendo possibile che il lavoro dei vari team non interferisca Il sistema viene quindi diviso in package La model management view consiste quindi di package e relazioni di dipendenza fra essi Mod 1 131

132 Model management View Package Ogni parte di un modello deve appartenere ad un package L allocazione delle parti deve però seguire principi rigorosi: funzionalità comuni, implementazione fortemente accoppiata, ecc. Una buona decomposizione in package è cruciale per incrementare la manutenibilità del modello/sistema I package possono essere innestati I package sono la base anche per il SCM Mod 1 132

133 Model management View Dipendenze fra Package Le dipendenze fra package sono derivabili dalle dipendenze fra i componenti che li costituiscono Normalmente un package non ha accesso ai contenuti di un altro package Le dipendenze sono rappresentate da frecce tratteggiate Mod 1 133

134 Model management View Package e relative relazioni <<subsystem>> Biglietteria Package Sottosistema fatto di packages Ordinare Packages fuori del sottosistema Servizio credito Prezzare Package astratto selezione del chiosco Queste sono variazioni del package di selezione posto Selezione del posto Dipendenza Generalizzazione di package Selezione dell operatore Dipendenza con package esterni DB posti Si noti che un subsystem è uno stereotipo di package Mod 1 134

135 Mod 1 135

136 Meccanismi di estensione Sono pensati per personalizzare il linguaggio di modellazione, in modo da agevolarne l ampio utilizzo I tool UML manipolano queste estensioni senza comprenderne la semantica (che deve essere comprensibile per il progettista e/o per opportuni postprocessori) Per questo motivo le estensioni sono memorizzate e manipolate come stringhe Mod 1 136

137 Meccanismi di estensione I meccanismi di estensione sono tre: Vincoli Tagged value Stereotipi Mod 1 137

138 Meccanismi di estensione Vincoli I vincoli sono espressi da un testo messo fra parentesi graffe {l accesso ai record deve essere sequenziale} Mod 1 138

139 Meccanismi di estensione Tagged value Sono coppie attributo/valore, usate per associare ai diagrammi informazioni per il project management, per la generazione di codice, ecc. Transazione di chiosco Author=Mike Pike, requirement=14.52, due=12/31/1999, status=designed Server tagged value di gestione progetto Form=standalone, optimize=time, search=random, library=rw, index=both tagged values di generazione codice Mod 1 139

140 Meccanismi di estensione Stereotipi Sono elementi di modellazione custom, essi possono essere associati a specifiche icone ed avere quindi un particolare simbolismo grafico <<database>> Prenotazioni Icona stereotipo Schedulatore di attività Chiosco Stereotipo di comunicazione <<ethernet>> Server Mod 1 140

141 Mod 1 141

142 Mod 1 142

143 Fasi di progetto Il modello classico (waterfall( waterfall) SYSTEM ENGINEERING REQUISITI E CONFIGURAZIONE DEL SISTEMA ANALISI MODELLO FUNZIONALE PROGETTO REALIZZAZIONE COLLAUDO MODELLO IMPLEMENTATIVO PRIMA RELEASE DI SISTEMA RELEASE FINALE DI SISTEMA USO E RITORNO Mod 1 MANUTENZIONE DELL INVESTIMENTO 143