software sistemi di controllo, software applicazioni industriali, … UML.pdf · 2011. 10. 2. ·...

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


…… 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:




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





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:




Questi principi sono di normale utilizzo nella progettazione delle strutture organizzate.

DEFINIZIONE

Mod 1 33

Principi dell’OOD





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


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


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


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


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


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


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


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


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


I meccanismi di estensione sono tre:

•Vincoli

•Tagged value

•Stereotipi

Mod 1 138


VincoliVincoli

I vincoli sono espressi da un testo messo fra parentesi graffe

{l’accesso ai record deve essere sequenziale}

Mod 1 139


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


•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


•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


•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


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


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


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


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


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


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


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


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


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



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



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


Formulare requisiti prestazionali eccessivi può portare a grossolani errori di progettazione. Un esempio classico è quello dei sistemi di regolazione.

Mod 1 170


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


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


software sistemi di controllo, software applicazioni industriali, … UML.pdf · 2011. 10. 2. ·...

Documents

Transcript of software sistemi di controllo, software applicazioni industriali, … UML.pdf · 2011. 10. 2. ·...