-
Mod 1 1
-
Mod 1 2
-
Mod 1 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. Questocomporta una disomogenea distribuzione del carico di elaborazione e il dimensionamento del sistema sulle condizioni di picco.
-
Mod 1 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 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 ‘user-friendly’.
-
Mod 1 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) ecomunicazione (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 7
Caratteristiche dei sistemi real-time
PROGETTO SVILUPPO COLLAUDO
Prestazioni elevate
Variabilità del carico
Interferenze temporali
Difficoltà di riprod. del campo
Architettura a processi concor.
Robustezza-Aff idabilitàFacilità d'uso
Impatto forte Impatto medio
-
Mod 1 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 9
Esempi di sistemi real-time
•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
•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
-
Mod 1 10
-
Mod 1 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 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 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 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 15
Criteri generali di progettazioneMODIFICABILITA’/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.
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.
APPLICAZIONE
FUNZIONE A
FUNZIONE B
FUNZIONE C
MODIFICHE
-
Mod 1 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 neweconomy il software è un asset aziendale strategico).
-
Mod 1 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 howsugli algoritmi di controllo implementati dal sistema.
-
Mod 1 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 19
Criteri generali di progettazioneROBUSTEZZA
Il sistema deve superare bene sia i test positivi, sia quelli negativi:
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.
TEST POSITIVI
TEST NEGATIVI
SISTEMA
FUNZIONA E’ ROBUSTO
-
Mod 1 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 user-friendly, 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 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
S. O. #1
INTERFACCIA
S. O. #2
-
Mod 1 22
Criteri generali di progettazione
SEMPLICITA’/ELEGANZA ARCHITETTURALE
Un sistema ‘elegante’ è semplice; se il sistema non èsemplice creerà piùproblemi del necessario.
Era necessario?
‘Fai le cose nel modo più semplice possibile, ma non più semplice’ (A. Einstein)
10FFA100
A200
AF00
FUNZIONE A
FUNZIONE B
FUNZIONE n
10FF3000 A100
A200
AF00
PUNTATORE
VETTORE DI
PUNTATORI
-
Mod 1 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 24
Criteri generali di progettazione
Si affina il modello osservandolo da più punti di vista…...
MODELLO DEL
SISTEMA
MODIFICABILITA’
ROBUSTEZZA
FUNZIONALITA’
PORTABILITA’
LEGGIBILITA’
SEMPLICITA’
PRESTAZIONI
FACILITA’ D’USO
-
Mod 1 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 26
-
Mod 1 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 28
Principi dell’OOD
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.
DEFINIZIONE
-
Mod 1 29
Principi dell’OOD
La definizione precedente evidenzia che l’OOD impiega nel SW design principi generali di organizzazione dei processi industriali.
-
Mod 1 30
Principi dell’OOD
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.
DEFINIZIONE
-
Mod 1 31
Principi dell’OOD
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
DEFINIZIONE
-
Mod 1 32
Principi dell’OOD
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.
DEFINIZIONE
-
Mod 1 33
Principi dell’OOD
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.
DEFINIZIONE
-
Mod 1 34
Principi dell’OOD - Evoluzione storica
Linguaggio macchina (operandi/operatori)
AssemblerC++ -VisualStudio
Linguaggi di terza generazione
Programmazione modulare
Librerie
Astrazione-Information hiding - Inheritance
Smaltalk - Ada
-
Mod 1 35
Principi dell’OOD
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.
La metafora dei SW ICLa metafora dei SW IC’’ ss
-
Mod 1 36
Principi dell’OOD
OOD e progettazione di sistemi realOOD e progettazione di sistemi real--timetime
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
TASK B
DB MemoryResident
-
Mod 1 37
Principi dell’OOD
OOD e progettazione di sistemi realOOD e progettazione di sistemi real--timetime
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 38
Principi dell’OOD
OOD e progettazione di sistemi realOOD e progettazione di sistemi real--timetime
La crescente potenza di elaborazione disponibile anche per La crescente potenza di elaborazione disponibile anche per alcune applicazioni alcune applicazioni embeddedembedded(ad esempio i telefoni (ad esempio i telefoni cellulari) crea le premesse per un impiego molto picellulari) crea le premesse per un impiego molto piùù ampio ampio delldell’’ OOD e dellOOD e dell’’ OOP nella progettazione di sistemi realOOP nella progettazione di sistemi real--time.time.
Questo consentirQuesto consentiràà molto presto il superamento della molto presto il superamento della tradizionale frattura fra disegno logico e disegno fisico dei tradizionale frattura fra disegno logico e disegno fisico dei sistemi realsistemi real--time.time.
-
Mod 1 39
Principi dell’OOD
OOD e OOPOOD 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 40
Principi dell’OOD
ClasseClasse
Identifica un insieme di oggetti che condividono gli stessi attributi, operazioni, metodi, relazioni e comportamenti. Essa rappresenta un concetto nel sistema da modellare.
OggettoOggetto
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).
Alcune definizioniAlcune definizioni
-
Mod 1 41
Principi dell’OOD
Alcune definizioniAlcune definizioni
MessaggioMessaggio
Il passaggio di informazione da un oggetto ad un altro, con l’aspettativa che venga eseguita un’attività.
EreditarietEreditariet àà
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 42
Principi dell’OOD
Vantaggi dellVantaggi dell’’ ODDODD
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 43
Principi dell’OOD
Identificazione degli oggettiIdentificazione 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 44
Principi dell’OOD
Identificazione degli oggettiIdentificazione 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 45
Principi dell’OOD
Identificazione degli oggettiIdentificazione degli oggetti
Vediamo un esempio.
Un computer centrale trasmette blocchi NC a un controllo numerico che contiene un software che legge ciascun bloccoNCe 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 sonoinviati 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
Principi dell’OOD
Identificazione degli oggettiIdentificazione degli oggetti
Vediamo un esempio.
Un computer centraletrasmette blocchi NCa un controllo numericoche contiene un softwareche legge ciascun bloccoNC e lo memorizza in un NC program file. I blocchi NC sono letti dal NC program file e decomposti in istruzioniper funzionidi posizionamento e speciali. Le istruzioni sono processate e codificate in comandi di controllo di posizionee comandi specialiche sono inviati agli azionamenti della macchina. I comandi dell’Operatoresono inviati al software NC attraverso una interfaccia a tastiera. I comandi dell’Operatore consentono all’Operatoredi 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 47
Principi dell’OOD
Identificazione degli oggetti
L’esempio consente di definire la seguente tabella di oggetti.
Oggetto Dominio Commento
Computer centrale PBlocco NC SControllo numerico PSoftware S Per NCNC program file S Composto di blocchi NCIstruzioni S Per funzioni di posizionamento e specialiFunzioni P Attività eseguite dagli azionamentiComandi di controllo posizione SComandi speciali SAzionamenti della macchina PComandi Operatore SInterfaccia a tastiera SOperatore PCRT PNC 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 numerico)
-
Mod 1 48
Principi dell’OOD
Identificazione degli oggettiIdentificazione 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 Operazioni
Blocco NC Leggi dal computer centraleLeggi dall'NC program fileInserisci in un NC program file esistente
NC program file MemorizzaCaricaPresenta su CRTEsegui
Istruzioni ProcessaCodifica
Comandi di controllo posizione Manda agli azionamentiComandi speciali Manda agli azionamentiComandi Operatore Inserisci da tastiera
-
Mod 1 49
-
Mod 1 50
-
Mod 1 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 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 53
-
Mod 1 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 55
-
Mod 1 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 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 1997.
-
Mod 1 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 59
-
Mod 1 60
Ulteriori definizioni
ClassifierClassifier
Un elemento del modello che descrive caratteristiche comportamentali e strutturali (classi, ma anche componenti, interfacce, sottosistemi).
MessageMessage
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 61
Ulteriori definizioni
MethodMethod
E’ la implementazione di un’operazione (un comportamento di una classe). Specifica l’algoritmo che produce il risultato di un’operazione.
SignalSignal
E’ una comunicazione asincrona fra oggetti. Le signalpossono avere parametri espressi come attributi.
-
Mod 1 62
-
Mod 1 63
La struttura di UML
Dominio View
Strutturale Use Case ViewStatic ViewPhisical View
Dinamico State machine ViewActivity ViewInteraction View
Model Management Model management View
-
Mod 1 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 65
La struttura di UML
Dominio strutturaleDominio strutturale
Use case Use case ViewView
Rappresenta il comportamento del sistema visto dall’esterno (utenti o altri sistemi).
StaticStatic ViewView
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.
PhisicalPhisical ViewView
Rappresenta la struttura fisica (implementativa) del sistema.
-
Mod 1 66
La struttura di UML
Dominio DinamicoDominio Dinamico
State State machinemachineViewView
Rappresenta il comportamento dinamico degli oggetti, mediante la modellazione del ciclo di vita degli oggetti di ciascuna classe.
ActivityActivity ViewView
E’ la vista che modella le elaborazioni e i flussi dati, mediante pseudo reti di Petri.
InteractionInteraction ViewView
Rappresenta le modalità di interazione fra oggetti.
-
Mod 1 67
La struttura di UML
Dominio di Dominio di ModelModel ManagementManagement
ModelModel management management ViewView
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 68
La struttura di UML
Sinottico dei formalismi grafici (diagrammi)Sinottico dei formalismi grafici (diagrammi)
Dominio View Formalismi grafici
Strutturale Use Case View Use case DiagramStatic View Class DiagramPhysical View Component Diagram/Deployment Diagram
Dinamico State machine View Statechart DiagramActivity View Activity DiagramInteraction View Sequence Diagram/Collaboration Diag ram
Model Management Model management View Class Diagram
-
Mod 1 69
-
Mod 1 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 71Top Mgmt
Clienti ABB
CQ
Ingegneria
Gestione dati di manutenzioneMgmt della
manutenzione
Presentazione dati sintetici sullostabilimento
Gestione dati di misura su pezziprodotti e carte di qualità
Gestione dati analitici diproduzioneSistema di raccolta
dati di stabilimento
Allarmistica/Supervisione Manutenzione
-
Mod 1 72
Use Case View
Tipi di relazioni fra use caseTipi 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 essaL’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
-
Mod 1 73
Piazza l’ordine
Use Case ViewTipi di relazioni fra use caseTipi di relazioni fra use case
Vendita telefonica
Controlla lo stato
AttoreNome del sistema
Use case
Comunicazione tra attori use case
Esegue l’ordine
Venditore
Addetto alla spedizione
Stabilisce il credito
Supervisore
Cliente
Nome use case
Confine di sistema
-
Mod 1 74
Use Case View
Esempio di relazione fra use caseEsempio di relazione fra use case
Piazza l’ordine Richiede catalogo
Use case base
Inserisce dati del cliente
Ordina il prodotto
Stabilisce il pagamento
Paga in contanti
Accorda un credito
Use case inclusi
Use case padre
Use case figlio
Estensione use case
-
Mod 1 75
-
Mod 1 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 77
Static View
Gli elementi chiave della static view
sono i classifier e le loro relazioni
-
Mod 1 78
Static View
Tipi di Tipi di classifierclassifier
Classificatore Funzione Notazione
Attore
Classe Nome
Nome(S)Classe in stato
Role:NomeRuolo di un classificatore
Componente
Un utente esterno del sistema
Un concetto nel sistema modellato
Una classe in un certo stato
Un classifier in un certo ruolo
Un pezzo fisico del sistema
-
Mod 1 79
Static View
Tipi di Tipi di classifierclassifier
Classificatore Funzione Notazione
Interfaccia
Nodo
I-nome
Segnale
Sottosistema
Use case
Un insieme di operazioni
Una risorsa di elaborazione
Comunicazione asincrona fra oggetti
Un package implementativo
Una funzionalità di una entità
-
Mod 1 80
Static View
Notazione grafica di una classeNotazione grafica di una classe
AbbonamentoSerie: Stringa
Categoria-di-prezzo: Categoria
Numero: Intero
Nome di classe
Acquista()
Prenota(Serie, Livello di posto)
Cancella()
Attributi
Operazioni
-
Mod 1 81
Static View
Tipi di relazioni fra Tipi di relazioni fra classifierclassifier
Relazione Funzione Notazione
Associazione
Dipendenza
Flusso
Connessione fra istanze di classi
Dipendenza consumatore/fornitore
Flusso fra due stati diversi di un oggetto in due istanti diversi
-
Mod 1 82
Static View
Tipi di relazioni fra Tipi di relazioni fra classifierclassifier
Relazione Funzione Notazione
Generalizzazione
Realizzazione
Utilizzo
Relazione figlio-padre
Relazione specifica-implementazione
Un oggetto richiede un altro per il suo corretto funzionamento
-
Mod 1 83
Static View
AssociazioneAssociazione
Successivo
Classe di allarme
0..1
0..1
Precedente (ruolo)
0..1
0..1
1..n
Allarme
*
Priorità
(nome dell’associazione)
Priorità
(auto-associazione)
-
Mod 1 84
Static View
Classe di associazioneClasse di associazione
Serve per fornire attributi ad una associazione
Reparto Linee di produzione1..n *
Prodotto annuo
Pezzi prodotti: interoPezzi scartati: intero
(attributi dell’associazione)
-
Mod 1 85
Static View
Qualificatore di una associazioneQualificatore di una associazione
Serve per identificare un unico oggetto in un insieme di oggetti correlati da una associazione
Sensore1
Data evento: data orario evento: orario
Evento0..1
(Qualificatore)
(Attributi del qualificatore)
-
Mod 1 86
Static View
AggregazioneAggregazione
E’ una associazione che aggrega le parti ad un tutto
Abbonamento
Performance
Aggregato
Parti
*
*
-
Mod 1 87
Static View
ComposizioneComposizione
E’ una forma di associazione più forte nella quale il composto gestisce le parti (i.e. le alloca/dealloca)
OrdineComposto
11
Dati del cliente
Linea d’ordineParti
1 *
-
Mod 1 88
Static View
GeneralizzazioneGeneralizzazione
Evento
Data Evento: Data
Acknowledge ()
Super classe (padre)
Allarme
Tipo Procedura: Intero
Esegui Procedura ()
Guasto
Codice Impianto: Intero
Richiesta Manutenzione ()
Sottoclasse (figlio)
-
Mod 1 89
Static View
GeneralizzazioneGeneralizzazione
•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 90
Bottone
Static View
RealizzazioneRealizzazione
Blocco di scelta
setDefault (scelta:scelta) getChoice():scelta
Scelta
1..* scelta
PopUpMenu
setDefault (scelta:bottone) getChoice():bottone
Stringa
scelta 1..*Vettore di Radio Button
setDefault (scelta:bottone) getChoice():bottone
1..* scelta
Relazione di realizzazione
specifica implementazione
-
Mod 1 91
Static View
RealizzazioneRealizzazione
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 92
Static View
DipendenzeDipendenze
Esistono vari altri tipi di relazioni di dipendenza, normalmente caratterizzati da Keyword:
•call
•friend
•instantiate
•use
•……
-
Mod 1 93
Static View
VincoliVincoli
Un vincolo è espresso da un testo fra parentesi graffe.
Persona Comitato
Membro di* *
Presidente di1 *
costrizione tra associazioni
sottoinsieme
-
Mod 1 94
Static View
ConclusioneConclusione
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 95
-
Mod 1 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 97
State machine View
•Gli eventi possono avere parametri che caratterizzano ciascuna loro istanza
EventiEventi
•Gli eventi non hanno durata
-
Mod 1 98
State machine View
Tipi di eventiTipi di eventi
Tipo di evento Descrizione Sintassi
Evento di chiamata
Evento di cambiamento
Signal
Richiesta sincrona da un oggetto che attende risposta
Un cambiamento nel valore di una espressione booleana
Evento a tempo assoluto o relativo
op (a:T)
when (exp)
sname (a:T)
Evento a tempo after (tempo)
Richiesta asincrona da un oggetto
-
Mod 1 99
State machine ViewEventiEventi
Un evento può essere descritto da un class diagram
InputEvent
tempoSegnale astratto
UserInput
device
Tasto del Mouse
locazione
Carattere della Tastiera
carattere
-
Mod 1 100
State machine View
•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)
TransizioniTransizioni
-
Mod 1 101
State machine View
Tipi di transizioniTipi di transizioniTipo di
transazioneDescrizione Sintassi
Azioni in entrata
Azioni in uscita
Transizione esterna
Normalmente azioni di set-up
Normalmente azioni di clean-up
Risposta ad un evento che non produce una transizione di stato
entry/azione
exit/azione
e (a:T)
Transizione interna
Azione associata a una transizione di stato
exp /azione
e (a:T) exp /azione
-
Mod 1 102
Importo>$25
State machine View
Esempio di state Esempio di state machinemachinesemplicesemplice
Attesa
Conferma Credito
Cancella Ordine
Esegui OrdineTransizione
Riceve ordine
rifiutato
Approvato/addebito-conto()Evento/Azione
Importo>$25Riceve ordine
Evento
Guard Condition
-
Mod 1 103
State machine View
•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 attivanoi meccanismi di ‘exit/entry’
Tipi particolari di transizioniTipi particolari di transizioni
-
Mod 1 104
State machine View
Esempio di stato con Esempio di stato con internalinternal transitiontransition
nome Immetti Password
entry/set echo to star;password.reset()
exit/set echo normal
digit/handle character
clear/password.reset()
help/display help
azioni di entrata e uscita
transizioni interne
-
Mod 1 105
State machine View
•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
Stati compostiStati composti
-
Mod 1 106
State machine View
Tipi di statiTipi di stati
Tipo di stato Descrizione Notazione
Stato semplice
Stato composto concorrente
Stato composto sequenziale
Stato con nessuna sottostruttura
E’ composto da più sottostati che risultano simultaneamente attivi, quando lo stato composto è attivo
Pseudostato che indica lo stato iniziale per lo stato che lo contiene
Stato iniziale
E’ composto da più sottostati, uno solo dei quali è attivo, quando lo stato composto è attivo
-
Mod 1 107
State machine ViewTipi di statiTipi di stati
Tipo di stato Descrizione Sintassi
Stato finale
Stato di giunzione
Stato storico
La sua attivazione indica che lo stato che lo contiene ha terminato l’attività
Indica una intera sotto-macchina a stati da includere nell’automa
Referenza a sottomacchina
Permette di tornare allo stato precedente, se si rientra in uno stato composto
H
Stato Stub
Include S
T
Pseudostato usato per collegare le frecce di transizione
Usato per ingressi e uscite da referenze a sottomacchine
-
Mod 1 108
State machine ViewEsempio di state Esempio di state machinemachinecon stato compostocon stato composto
Idle
Inserim. carta
Transazione completata
Una transizione esterna annulla un’attività interna
Tasto “cancella”
Referenza sottomacchina
Stato inizialefallisce
Stato finaleInclude Identificazione
Uscita forzataUscita normale /reset selezione
SelezionaPrende(posto) / aggiunge alla selezione(posto)
Tasto “resume” Tasto “compra”
Transazione completata
Tasto “conferma”
Conferma
VendeEntry/vende()
Transizione interna
Azione atomica
AcquistoExit /espulsione carta
-
Mod 1 109
State machine View
•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 completiontransition per uno stato composto
Regole per la gestione di stati compostiRegole per la gestione di stati composti
-
Mod 1 110
State machine ViewEsempio di state Esempio di state machinemachinecon stato con stato
composto concorrentecomposto concorrente
Acquisizione misure
Entry /inizializza ADC e timer di campionamento
Attesa
Elaborazione misura
Fine DT
Entry /reinizializza timer
Confronto soglia
Notifica allarme
normale
allarme
Aggiornamento log misure
-
Mod 1 111
-
Mod 1 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 113
Activity ViewEsempio di Esempio di activityactivity diagramdiagram
Inizial.ordine
Guard conditionOrdine singolo
branch
abbonamento barra (biforcazione)
Assegna posti
Addebito conto
Merge (unbranch)
Invio biglietti
Assegna posti
Assegna bonus
Addeb. carta di credito
Vie alternative
barra (associazione)
BoxOffice::ElaboraOrdine
Threadconcorrenti
-
Mod 1 114
Activity ViewEsempio di Esempio di activityactivity diagramdiagram con corsiecon corsie
Le corsie (swimlanes) sono usate per raggruppare le attività per unitàorganizzativa, risorsa di elaborazione, layer di architettura, ecc.
Cliente Venditore Magazzino
Richiesta servizio
Paga
Ordine piazzato
Ordine consegnato
Raccolta ordine
Prende l’ordine
Consegna l’ordine
Ordine inserito
Ordine entrato
Inserisce l’ordine
-
Mod 1 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 116
-
Mod 1 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 118
Interaction View
•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
CollaborazioniCollaborazioni
-
Mod 1 119
Interaction View
•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
InterazioniInterazioni
-
Mod 1 120
Interaction ViewSequenceSequenceDiagramDiagram
Il tempo evolve dall’alto verso il basso
Attore esterno
:Chiosco :Server :Servizio Credito
Oggetto attivo
Carta inserita (cliente)
Data scelta(data)
Offerta (posti disp.)
Selezione (posti)
Stampa (ordine)
Messaggiosottomissione (ordine)
OK
Addebito (cliente, importo)
Autorizza
Lifeline(attivo)
-
Mod 1 121
Interaction View
CollaborationCollaboration DiagramDiagram
In questo caso la sequenza è rappresentata dal numero progressivo
Richiedente
Richiesta (ordine, cliente) :Collezione
ordini
2:costo:=prenota(ordine):BigliettiDB
3:addebito(cliente,costo)
:Ufficio Crediti
1:Controllo-credito(cliente)
Navigazione one-way
Flusso dei messaggi
Numero di sequenza
Ruolo del classifier
-
Mod 1 122
Interaction View
•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.
Aree di impiegoAree di impiego
-
Mod 1 123
Interaction View
PatternPattern
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 124
Interaction View
PatternPattern
Nel pattern ‘Presentazione misure’ si ha ‘Sensore analogico’ nel ruolo di ‘Sorgente dati’ e ‘Trend’ nel ruolo di ‘Oggetto HMI’
Sensore analogico 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
-
Mod 1 125
-
Mod 1 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 dislocazionedei componenti sui nodi di elaborazione
-
Mod 1 127
Physical View
Componente ed interfacce esposteComponente ed interfacce esposte
Componente DizionarioSpell-check
Sinonimiinterfacce
-
Mod 1 128
Physical View
ComponentComponentDiagramDiagram
Componente
Transazioni
Conto
Aggiornamento
Componente stereotipato
interfaccia
ATM-GUI
Dipendenza d’uso
Dipendenza di realizzazione
-
Mod 1 129
Physical View
DeploymentDeploymentdiagramdiagram
server:BankServer
:Transazioni
Istanza di componente
contoDB:Conto
Linea di comunicazione
Istanza di nodo
client:ATMKiosk
aggiornamento
Interfaccia
:ATM-GUI
dipendenza
-
Mod 1 130
-
Mod 1 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 132
Model management ViewPackagePackage
•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 133
Model management View
Dipendenze fra PackageDipendenze 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 134
Model management ViewPackage e relative relazioniPackage e relative relazioni
Si noti che un ‘subsystem’ è uno stereotipo di package
Biglietteria
Sottosistema fatto di packages
Ordinare
Prezzare
Selezione del posto
selezione del chiosco
Selezione dell’operatore
Package
Dipendenza
Package astratto
Generalizzazione di package
Queste sono variazioni del package di selezione posto
Servizio credito
DB posti
Packages fuori del sottosistema
Dipendenza con package esterni
-
Mod 1 135
-
Mod 1 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 post-processori)
•Per questo motivo le estensioni sono memorizzate e manipolate come stringhe
-
Mod 1 137
Meccanismi di estensione
I meccanismi di estensione sono tre:
•Vincoli
•Tagged value
•Stereotipi
-
Mod 1 138
Meccanismi di estensione
VincoliVincoli
I vincoli sono espressi da un testo messo fra parentesi graffe
{l’accesso ai record deve essere sequenziale}
-
Mod 1 139
Meccanismi di estensione
TaggedTaggedvaluevalue
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
tagged value di gestione progetto
Server
Form=standalone, optimize=time, search=random, library=RW, index=both
tagged values di generazione codice
-
Mod 1 140
Meccanismi di estensioneStereotipiStereotipi
Sono elementi di modellazione ‘custom’, essi possono essere associati a specifiche icone ed avere quindi un particolare simbolismo grafico
Prenotazioni
Chiosco Server
Schedulatore di attività
Stereotipo di comunicazione
Icona stereotipo
-
Mod 1 141
-
Mod 1 142
-
Mod 1 143
Fasi di progettoIl modello classico (Il modello classico (waterfallwaterfall ))
SYSTEM ENGINEERING
ANALISI
PROGETTO
REALIZZAZIONE
COLLAUDO
USO E MANUTENZIONE
REQUISITI E CONFIGURAZIONE DEL SISTEMA
MODELLO FUNZIONALE
MODELLO IMPLEMENTATIVO
PRIMA RELEASE DI SISTEMA
RELEASE FINALE DI SISTEMA
RITORNO DELL’INVESTIMENTO
-
Mod 1 144
Fasi di progettoArticolazione delle attivitArticolazione delle attivitàà di di
ingegneria HW e SWingegneria HW e SW
SYSTEM ENGINEERING
1 USER REQ. DEF. SYSTEM REQ. DEF. EXT. WORLD INTER. SW CONFIGURATION
IDEM IDEM IDEM
HW CONFIGURATION
ANALYSIS 2 FUNCTIONAL ANALY. (IDEM)
DESIGN 3A/D DESIGN PLATFORM QUALIFIC. TEST DESIGN
(IDEM) IDEM (IDEM)
IMPLEMENTA-TION
4 CODE UNIT TESTSYSTEM INTEGRATION
(IMPLEMENTATION)(SUBSYSTEM TEST)
IDEM
FASE SW HW
-
Mod 1 145
Fasi di progettoArticolazione delle attivitArticolazione delle attivitàà di di
ingegneria HW e SWingegneria HW e SW
IN-HOUSE TESTING
5 SYSTEM TUNING FAT IDEM
ON-FIELD TESTING
6 SYSTEM MONITOR SYSTEM TUNING BABY SITTING
IDEM
OPERATION & MAINTENANCE
7CORRECTIVE PERFECTIVE MAINT. ADAPTIVE
IDEM
FASE SW HW
-
Mod 1 146
Fasi di progettoLa documentazione prodottaLa documentazione prodotta
SYSTEM ENGINEERING
ANALISI
PROGETTO
REALIZZAZIONE
COLLAUDO
USO E MANUTENZIONE
SOFTWARE CONFIG.
REPOSITORY
USER/SYSTEM REQUIREMENT EXTERNAL WORLD INTERFACE
SPECIFICHE FUNZIONALI
PROGETTO ARCHITETTURALE DETTAGLIATO
PROGETTO DEI TEST
CODICE
CODICE TEST REPORT RELEASE NOTES
CODICE CHANGE REPORT
-
Mod 1 147
-
Mod 1 148
Unified Development Process
•Proposto da Jacobson, Booch, Rumbaugh
•Cerca di proporre un processo di sviluppo adatto per fronteggiare le nuove sfide della tecnologia: sistemi sempre più complessi con un time-to-market sempre più breve
-
Mod 1 149
Unified Development Process
•Si devono identificare gli use case per ogni tipo di utente
•Pensare in termini di use case equivale a pensare in termini di ‘valore per gli utenti’
UP è use-case driven
-
Mod 1 150
Unified Development Process
•E’ importante individuare i principi architetturali che debbono ispirare la concezione del sistema
•Essi sono elaborati per realizzare in modo efficace gli use case chiave (normalmente il 5-10% degli use case del sistema)
UP è architecture-centric
-
Mod 1 151
Unified Development Process
•Sviluppo il sistema in modo incrementale, con una sequenza di iterazioni concepita razionalmente
•Sviluppare incrementalmente consente di:1) non giocarsi il bdgt in un solo colpo2) identificare prima gli imprevisti3) fare operare il team di sviluppo su obiettivi a
breve e quindi più chiari4) assorbire meglio le richieste di cambiamenti in
corso d’opera
UP è iterativo e incrementale
-
Mod 1 152
Unified Development Process
Il sistema, dalla nascita alla morte, si sviluppa attraverso una serie di cicli. Ognuno di essi porta al rilascio di una release impiegabile dagli utenti (ovviamente le prime release saranno fortemente ridotte, ovvero includeranno solo gli use case base)
I cicli
-
Mod 1 153
Unified Development Process
Ogni ciclo evolve attraverso quattro fasi
•Inception: inquadro le idee chiave
•Elaboration: identifico l’architettura
•Construction: realizzo
•Transition : rilascio agli utenti.
A loro volta le fasi si compongono di varie iterazioni
Fasi di un ciclo
-
Mod 1 154
Unified Development Process
Le attività progettuali non sono chiuse a compartimenti stagni
Fasi di un ciclo
Requirements
Analysis
Design
Implementation
Test
Un’iterazione nella fase di elaborazione
Iter. #1
Iter. #2
Iter. #n-1
Iter. #n
Core WorkflowsFasi
Inception Elaboration Construction Transiction
Iterazioni
-
Mod 1 155
-
Mod 1 156
Principali cause di criticità di progetto
I requisiti di progetto non sono chiariI requisiti di progetto non sono chiari
Spesso i progetti falliscono per l’incapacità di definire requisiti chiari
-
Mod 1 157
Principali cause di criticità di progetto
Tempi di sviluppo troppo breviTempi di sviluppo troppo brevi
Oggi è la criticità più ricorrente, essa produce i seguenti effetti:
•la gestione del progetto tende a diventare predittiva, perché non c’è tempo per correggere gli errori,•ma la fretta aumenta il numero di errori,•il budget di progetto va quindi fuori controllo,•e il progetto viene spesso completato con una qualitàinferiore e in tempi superiori a quelli conseguibili con una pianificazione lavori più realistica
-
Mod 1 158
Principali cause di criticità di progetto
Tempi di sviluppo troppo breviTempi di sviluppo troppo brevi
Capita spesso che i tempi di sviluppo brevi siano determinati dal famoso ‘effetto Fiera’.Raramente si capisce che è meglio portare in Fiera un prototipo e lasciar lavorare tranquilla la R&D.
-
Mod 1 159
Principali cause di criticità di progetto
Piattaforme software Piattaforme software inadeguate/instabiliinadeguate/instabili
•Il desiderio di impiegare piattaforme di ampia diffusione commerciale, porta sovente all’adozione di ambienti operativi non concepiti per il supporto di applicazioni real-time
•Le tradizionali piattaforme real-time, a loro volta, nel tentativo di integrare rapidamente funzioni tipiche delle piattaforme più diffuse, escono dai reparti di R&D del produttore troppo rapidamente e senza aver subito un collaudo opportuno
-
Mod 1 160
Principali cause di criticità di progettoPiattaforme hardware Piattaforme hardware
sottodimensionatesottodimensionate
•Spesso le applicazioni real-time (in particolar modo quelle embedded) debbono essere replicate in vari esemplari,•Può quindi succedere che, nel tentativo di risparmiare sull’hardware, si impieghi un’architettura (CPU, Memoria, I/O) troppo povera,•Può quindi succedere che per risparmiare 10 $ sul costo ripetitivo dell’hardware, si incrementi il costo del software (sviluppo + manutenzione) di 100.000$,•Ma ciò ha senso solo se devo produrre almeno 10.000 sistemi, e, a volte, neppure in quel caso.
-
Mod 1 161
Principali cause di criticità di progetto
Errori nella gestione del ciclo di vitaErrori nella gestione del ciclo di vita
•Un prodotto ben architettato può reggere un ciclo di vita lungo (in pratica conviene investire in architetture)•Però nessun prodotto è eterno•Tentare la re-ingegnerizzazione di un prodotto obsoleto è un errore gravissimo
-
Mod 1 162
Principali cause di criticità di progetto
Errori nella gestione della V&VErrori nella gestione della V&V
L’attività di V&V va correttamente gestita per
•Tempi•Strumenti e risorse•Strategie di test
-
Mod 1 163
Principali cause di criticità di progetto
Interazioni fra problematiche HW, SW e di Interazioni fra problematiche HW, SW e di processo controllatoprocesso controllato
Un buon sistema real-time è normalmente ottenuto armonizzando architettura hardware e software
-
Mod 1 164
Principali cause di criticità di progetto
Interazioni fra problematiche HW, SW e di Interazioni fra problematiche HW, SW e di processo controllatoprocesso controllato
Un sistema real-time richiede spesso la gestione di concurrent engineering:•elettro-meccanica•elettronica•software.D’altra parte i problemi di concurrent engineeringnon sono solo tecnici, ma anche gestionali, di planning, etc.
-
Mod 1 165
Principali cause di criticità di progetto
Interazioni fra problematiche HW, SW e di Interazioni fra problematiche HW, SW e di processo controllatoprocesso controllato
Spesso i problemi nascono dall’impossibilità di replicare in laboratorio la situazione in cui il sistema si troverà ad operare in campo.
-
Mod 1 166
-
Mod 1 167
-
Mod 1 168
Identificazione dei requisititemporali e prestazionali
• I requisiti temporali e prestazionali sono di primaria importanza nei sistemi real-time
• E’ quindi opportuno uno studio accurato di questo aspetto del problema
• Una formulazione del tipo “ il più rapidamente possibile” evidenzia l’assenza di questo studio
-
Mod 1 169
Identificazione dei requisititemporali e prestazionali
Formulare requisiti prestazionali eccessivi può portare a grossolani errori di progettazione. Un esempio classico è quello dei sistemi di regolazione.
-
Mod 1 170
Identificazione dei requisititemporali e prestazionali
I sequence diagram possono costituire un eccellente strumento per la identificazione dei requisiti temporali
: sorgente : servente
T=1 sec. (min)3 sec. (tip.)5 sec. (max.)
risposta
Evento
-
Mod 1 171
-
Mod 1 172
Non sbagliare la prima mossa:architettura di sistema
• Un sistema con una buona architettura è come un apparato meccanico con un buon telaio
• Risulterà:• robusto• efficace/efficiente• espandibile
• Il tempo dedicato alla definizione e all’affinamento dell’architettura è sovente troppo esiguo
-
Mod 1 173
-
Mod 1 174
Problematiche connesse alla piattaforma hardware
• Spesso si progetta l’hardware e poi gli si progetta addosso il software
• Questo approccio è sbagliato perché sovente èpiù facile risolvere i problemi nel dominio hardware che nel dominio software
• Architettura hardware e software vanno progettati/dimensionati insieme e in modo armonico
-
Mod 1 175
-
Mod 1 176
Problematiche connesse al processo fisico controllato
PROBLEMA CONSEGUENZA
Non è sufficientemente conosciuto
Si cerca di realizzare un controllo non identificato
Si conoscono le funzionalitàprimarie ma non le eccezioni
Il controllo non saràrobusto
Non riesco a replicare il processo in laboratorio
Il controllo non sarà collaudabile
Decido di mettere a punto il sistema in campo
Ammesso che superi la “crisi di panico”, mi costerà almeno 10 volte di più che in laboratorio
Accertatevi di conoscere adeguatamente il processo
-
Mod 1 177
-
Mod 1 178
Costruisci qualcosa che puoi collaudare
Sistema REAL-TIME
Se il traffico sui link di comunicazione è intenso, potrebbe essere arduo collaudare questo sistema
Unità periferiche
-
Mod 1 179
Costruisci qualcosa che puoi collaudare
Se proprio si deve usare questa architettura èopportuno prevedere un SW di log, che consenta selettivamente di mettere in traccia uno o più link di comunicazione
-
Mod 1 180
Si tenga anche presente che architetture distribuite applicate a sistemi software closely-coupled, possono far emergere facilmente delle “race conditions”.
Costruisci qualcosa che puoi collaudare