Dipartimento di Informatica e Sistemistica Procedure di Progettazione e di Documentazione per il...

Dipartimento diInformatica e Sistemistica

Procedure di Progettazione e di Documentazione per il

Controllo di Sistemi Complessi

Prof. ALESSANDRO DE CARLIDott. Ing. VINCENZO SURACI

ANNO ACCADEMICO 2011-2012Corso di AUTOMAZIONE 1

PROLOGO

2

STRUTTURA DEL NUCLEO TEMATICO:1. STRUTTURA DI UN SISTEMA CONTROLLATO2. GESTIONE DI UN PROGETTO COMPLESSO3. GESTIONE DI UN PROGETTO SPFTWARE4. PROGETTAZIONE DI UN SISTEMA COMPLESSO5. MODELLO E SIMULAZIONE DI UN SISTEMA

COMPLESSO6. UNIFIED MODELLING LANGUAGE (UML)7. STANDARD DI PROGETTAZIONE ESA-PSS058. ESEMPIO DI PROGETTAZIONE E

DOCUMENTAZIONE CON UML

PROLOGO

3

STRUTTURA DI UN SISTEMA CONTROLLATO

SISTEMADA

CONTROLLARESTRUMENTAZIONE

MODALITÀ DI CONTROLLO


4

PROGETTAZIONE DI UN SISTEMA COMPLESSO


SISTEMA DA CONTROLLARE STRUMENTAZIONE



SISTEMA DINAMICO COMPLES-SO A PIÙ VARIABILI DI INGRESS0 E PIÙ VARIABILI DI USCITA

• ATTUATORI• DISPOSITIVI DI MISURA• RETE DI COMUNICAZIONE• DISPOSITIVI DI ELABORAZIONE

• HARDWARE (CPU, SCHEDE I/O, etc.)• SISTEMA OPERATIVO REAL TIME

ALGORITMO DI CONTROLLO

5



GRADI DI LIBERTÀ NELLA PROGETTAZIONE

STRUMENTAZIONE


SCELTA

SISTEMADA

CONTROLLARE

ASSEGNATO

GRADI DI LIBERTÀ NELLA PROGETTAZIONE


6

SCELTA

SISTEMADA



DOCUMENTAZIONE DELLA PROGETTAZIONE

7


DOCUMENTAZIONE

DOCUMENTAZIONE

DOCUMENTAZIONE

DOCUMENTAZIONE

SISTEMADA



VERIFICA DI VALIDITÀ DEL PROGETTO

VERIFICA

TRAMITE

SIMULAZIONEVERIFICA

TRAMITE

SIMULAZIONE

VERIFICATRAMITE

SIMULAZIONE

8


VERIFICA DI VALIDITÀ

PROLOGO

9

GESTIONEDI UN PROGETTO COMPLESSO

RUOLO DEI REQUISITI DEL SISTEMA DA PROGETTARE 10


• È LA PERSONA CHE GESTISCE IL PROGETTO PER PORTARE A TERMINE GLI OBIETTIVI, TRAMITE LA CONOSCENZA E L’APPLICAZIONE DI TECNICHE DI PROJECT MANAGEMENT, DURANTE LE VARIE FASI DI VITA DEL PROGETTO

• UNA GESTIONE EFFICACE DI UN PROGETTO PREVEDE LA VALIDAZIONE DI COSA VIENE PRODOTTO TRAMITE OPPORTUNE E MIRATE VERIFICHE

OBIETTIVI

TEMPOCOSTI

PROJECT MANAGER

1. SCOPO DEL PROGETTO

2. PROGETTAZIONE CONCETTUALE

3. PREINGEGNERIA

4. INGEGNERIA

5. PROGETTAZIONE DEGLI APPARATI

6. REALIZZAZIONE DEGLI APPARATI

7. COLLAUDO PRESSO I FORNITORI

8. INSTALLAZIONE

9. ADDESTRAMENTO

10. CURVA DI APPRENDIMENTO

PROBLEMI EMERGENTISCOPO DEL PROGETTO 11

FASE 1 - SCOPO DEL PROGETTO

SPECIFICHE

OBIETTIVI

CAPACITÀ PRODUTTIVA

EFFICIENZA DELLA PRODUZIONE

PARAMETRI OPERATIVI

INVESTIMENTI NECESSARI

TEMPO PER IL COMPLETAMENTO DELL’ORDINETEMPO DI ATTESA PER L’ORDINAZIONE

SCARTITEMPO MEDIO FRA I GUASTI

COSTI PREVISTITEMPI DI REALIZZAZIONE (COMPRESO L’APPRENDIMENTO)

INDIVIDUAZIONE DI:

DEL PRODOTTO (STRUTTURA, PROPRIETÀ)DELL’IMPIEGO DEL PRODOTTO


PROBLEMI EMERGENTIPROGETTAZIONE CONCETTUALE 12

FASE 2 - PROGETTAZIONE CONCETTUALE

ARCHITETTURA DEL PROCESSO DI PRODUZIONE

COMPOSIZIONE COSTRUTTIVA DEL PRODOTTO

PROVE SULL’IMPIANTO PILOTA (REALTÀ VIRTUALE) – VERIFICA

CARATTERISTICHE OPERATIVE DEL PROCESSO

CARATTERISTICHE FUNZIONALI DEL PRODOTTO

PARAMETRI OPERATIVI DELLE UNITÀ PRODUTTIVE

COSTO FINALE DEL PRODOTTO FINITO

PRIME IPOTESI DI REALIZZAZIONE


PREINGEGNERIA 13

FASE 3 – PRE-INGEGNERIA

PROGETTO DI MASSIMA DELLA STRUTTURA DEL SISTEMA DI PRODUZIONE (DAL MODELLO MATEMATICO AL MODELLO STRUTTURALE)

ANALISI DELLA FUNZIONALITÀ DEL PROCESSO PRODUTTIVO DEFINITO IN FASE DI PROGETTAZIONE

INDIVIDUAZIONE DELLE CONDIZIONI DI CRITICITÀ CON IL METODO FMEA (FAILURE MODE EFFECTS ANALISYS)

SCAMBIATORE DI CALORE

RISCALDAMENTOMISCELA

TEMPERATURA MASSIMA

UNITÀ PRODUTTIVA

NOTEFUNZIONI SPECIFICHE

CRITICITÀ PARAMETRI OPERATIVI

PORTATA VAPORE

PERICOLO DI CONDENSAZIONE

IDENTIFICAZIONE DEI PARAMETRI SENSIBILI NELLE VARIE AREE CRITICHE DELL’IMPIANTO E DEFINIZIONE ATTREZZATURE SU CUI EFFETTUARE PROVE


PROBLEMI EMERGENTIINGEGNERIA 14

FASE 4 - INGEGNERIA

DEFINIZIONE SPECIFICHE COSTRUTTIVE DEGLI APPARATI

RICHIESTA DI FORNITURA DEGLI APPARATI

REVISIONE CONTINUA ED ITERATIVA DI

SI EFFETTUANO PROVE INDUSTRIALI SU PRODOTTI OD ALTRO, UTILIZZANDO MACCHINE ESISTENTI MODIFICATE O PROTOTIPI, PER VERIFICARE LA FATTIBILITÀ INDUSTRIALE

CARATTERISTICHE OPERATIVE DEL PROCESSO

CARATTERISTICHE FUNZIONALI DEL PRODOTTO

PARAMETRI OPERATIVI DELLE UNITÀ PRODUTTIVE

COSTO DEL PRODOTTO FINITO


PROBLEMI EMERGENTIPROGETTAZIONE DEGLI APPARATI 15

FASE 5 - PROGETTAZIONE DEGLI APPARATI

ANALISI DELLE OFFERTE DEI FORNITORI E VERIFICA COSTI

ORDINE DEGLI APPARATI E DELLE ATTREZZATURE

PIANO DI GESTIONE GENERALE DI PROGETTO E TEMPISTICHE

PROGETTO E DISEGNO DI DETTAGLIO CON I METODI:

CURVA DI APPRENDIMENTO

FMEA (FAILURE MODE EFFECTS ANALISYS)

PMA (PHENOMENON/PHYSICAL MECHANISM ANALISYS)

OPL (ONE POINT LESSON - MAINTENANCE PROCESS DESIGN)


PROBLEMI EMERGENTIREALIZZAZIONE DEGLI APPARATI 16

FASE 6 - REALIZZAZIONE DEGLI APPARATI

DETTAGLIO DEI TEMPI DELLE FORNITURE VALUTATI CON LA TECNICA DELLA REVISIONE TEMPORALE DEI PROGETTI

REALIZZAZIONE ED ASSEMBLAGGIO

PROVE PRELIMINARI SULLE APPARECCHIATURE CRITICHE

MODIFICHE E RIPROGETTAZIONE DI PARTICOLARI, MIGLIORABILI IN SEGUITO ALLE PROVE ESEGUITE


PROBLEMI EMERGENTIINSTALLAZIONE 17

FASE 7 - COLLAUDO PRESSO I FORNITORI

FASE 8 - INSTALLAZIONE

PREPARAZIONE DELL’AREA ATTREZZATA (BASAMENTI,..)

PREDISPOSIZIONE DEI SERVIZI (ENERGIA ELETTRICA, ACQUA, GAS, ARIA COMPRESSA, . . .)

INSTALLAZIONE DELLE APPARECCHIATURE

ALLACCIAMENTO DELLE APPARECCHIATURE AI SERVIZI

PROVE DI FUNZIONAMENTO SINGOLE PUNTO PER PUNTO


PROBLEMI EMERGENTIPROVE DI FUNZIONAMENTO 18

FASE 9 - PROVE DI FUNZIONAMENTO DELLE APPARECCHIATURE ED ADDESTRAMENTO

MESSA IN FUNZIONE DELLE APPARECCHIATURE

VERIFICA PRESTAZIONI MECCANICHE A VUOTO

PROVE DI PRODUZIONE CON PERSONALE IN LINEA

PROVE DI PRODUZIONE A FUNZIONALITÀ RIDOTTA

ADDESTRAMENTO DEL PERSONALE OPERATIVO E DI MANUTENZIONE

PROVE PROLUNGATE DI AFFIDABILITÀ DEGLI APPARATI


PROBLEMI EMERGENTIMESSA IN ESERCIZIO 19

FASE 10 – MESSA IN ESERCIZIO SEGUENDO LA CURVA DI APPRENDIMENTO

INIZIO DELLA PRODUZIONE A POTENZIALITÀ RIDOTTA

INCREMENTO DELLA PRODUZIONE FINO AL RAGGIUNGIENTO DELLA POTENZIALITÀ DI REGIME

CLASSIFICAZIONE DEGLI EVENTUALI PROBLEMI RISCONTRATI E DELLE CONTROMISURE ADOTTATE


PROLOGO

20

GESTIONEDI UN PROGETTO SOFTWARE

PIANIFICAZIONE DELLA GESTIONE DEL SOFTWARE 21

DEFINIZIONE FINALITÀ RICHIESTE DAL COMMITTENTE

DEFINIZIONE DELLE PRESTAZIONI DESIDERATE

PROGETTAZIONE DELLA ARCHITETTURA DI SISTEMA

ASSEMBLAGGIO

MODALITÀ DI UTILIZZAZIONE

MESSA IN ESERCIZIO

PROGETTAZIONE DELLE SINGOLE PARTI

REALIZZAZIONE DELLE SINGOLE PARTI

PROVE DI VALIDAZIONE



DEFINIZIONE FINALITÀ RICHIESTE DAL COMMITTENTE

DEFINIZIONE DELLE PRESTAZIONI DESIDERATE

PROGETTAZIONE DELLA ARCHITETTURA DEL SISTEMA CONTROLLATO

PROGETTAZIONEDELLE SINGOLE PARTI

ASSEBLAGGIO E PROVE DI VALIDAZIONE

MODALITÀ DI UTILIZZAZIONE

DOCUMENTAZIONE

MESSA IN ESERCIZIO



DEFINIZIONEESIGENZE UTENTE

DEFINIZIONEESIGENZE SOFTWARE

PROGETTAZIONE DELLA ARCHITETTURA

PROGETTAZIONE DETTAGLIATA

PRODUZIONE DEL CODICE

TRASFERIMENTO

FUNZIONAMENTOMANTENIMENTO



DEFINIZIONEESIGENZE UTENTE

DEFINIZIONEESIGENZE SOFTWARE

PROGETTAZIONE DELLA ARCHITETTURA

PROGETTAZIONE DETTAGLIATA

PRODUZIONEDEL CODICE

PROVE PER L’ACCETTAZIONE

PROVE SU OGNI MODULO

PROVE SULLA INTEGRAZIONE DEI MODULI

PROVE SULSISTEMA COMPLETO

VERIFICA E VALIDAZIONE

VERIFICA E VALIDAZIONE

VERIFICA

VALIDAZIONE


PROLOGO

25

PROGETTAZIONEDI UN SISTEMA COMPLESSO

26REMINISCENZE LETTERARIE

Apri la mente a quel ch' io ti paleso e fermalvi entro; ché non fa scienza,

sanza lo ritenere, avere inteso.

Due cose si convegnono a l' essenzadi questo sacrificio: l' una è quelladi che si fa; l' altr' è la convenenza.

Paradiso, CANTO 5, 41-45


http://upload.wikimedia.org/wikipedia/commons/4/49/Page_of_The_Divine_Comedy.jpg

FORMAZIONE CULTURALE DELL’ESPERTO 27

IMPEGNO TEMPORANEO INTRAPRESO ALLO SCOPO DI CREARE UN PRODOTTO, UN SERVIZIO O UN RISULTATO MISURABILE E VERIFICABILE

«TEMPORANEO», SIGNIFICA CHE HA UN INIZIO E UNA FINE

LA FINE SI RAGGIUNGE QUANDO:• VENGONO OTTENUTI GLI OBIETTIVI;• SI DIMOSTRA CHE È IMPOSSIBILE RAGGIUNGERE GLI OBIETTIVI;• IL PROGETTO NON È PIÙ NECESSARIO O VIENE CHIUSO.

«TEMPORANEO» NON SIGNIFICA DI BREVE DURATA

LA PROGETTAZIONE NON È UN’ATTIVITÀ RIPETITIVA O STANDARDIZZABILE.

PROGETTAZIONE


APPROCCIO CONVENZIONALE 28

APPROCCIO CONVENZIONALEALLE NUOVE REALIZZAZIONI

COMMITTENTE

PROGETTAZIONE

VALIDAZIONE DELLA FUNZIONALITÀ E DELLE PRESTAZIONI

FINALITÀ E FUNZIONALITÀ

PRESTAZIONIE SPECIFICHE

MESSA IN ESERCIZIO

MODIFICHE

REALIZZAZIONE DEL PROGETTO

COSTOELEVATO


FALLIMENTO

SOVRADIMENSIONAMENTOABBATTIMENTO DELLE

PRESTAZIONI

29

APPROCCIO INNOVATIVOALLE NUOVE REALIZZAZIONI

COMMITTENTE

PROGETTAZIONE

VALIDAZIONE DELLA FUNZIONALITÀE DELLE PRESTAZIONI

FINALITÀ EFUNZIONALITÀPRESTAZIONIE SPECIFICHE

MESSA IN ESERCIZIO

MODIFICHEESSENZIALI

REALIZZAZIONE DEL PROGETTO IN REALTÀ VIRTUALE

COSTOBASSO

VERIFICA DELLA FUNZIONALITÀ E DELLE PRESTAZIONI

REALIZZAZIONE DEL PROGETTO MODIFICATO

MODIFICHE MARGINALI

APPROCCIO INNOVATIVO


FAIL

FAIL

CORREZIONE DELLAMODALITÀ DI CONTROLLO

COSTOLIMITATO

CORREZIONEDEL MODELLO

30COSTI E INVESTIMENTI DI UN SISTEMA CONTROLLATO

PROGETTAZIONECONCETTUALE

PROGETTAZIONEPER LA

REALIZZAZIONE

REALIZZAZIONEE MESSA

IN ESERCIZIO

PRODUZIONEMODIFICHE

AGGIORNAMENTI

CICLO DI VITA DI UN SISTEMA CONTROLLATO

CO

ST

O D

EL

SIS

TE

MA

CO

NT

RO

LLA

TO

D

UR

AN

TE

IL

CIC

LO D

I V

ITA

SPESE

RESA DEGLI

INVESTIMENTI


31COSTI E INVESTIMENTI DI UN SISTEMA CONTROLLATO


come lo spiega il committente

come lo interpreta il capo progetto

come lo progetta l’analista

come lo progetta l’informatico

come lo progetta il fornitore

come è documentato il progetto

come è realizzato dall’installatore

come è stato fatturato al cliente

come è stata effettata la manutenzione

ECCO COSA VOLEVA IL COMMITTENTE

UNA DELLE PRINCIPALI CAUSE DI FALLIMENTO DI UN PROGETTO È LA SCARSA DEFINIZIONE E COMPRENSIONE DEGLI OBIETTIVI

• ATTUALMENTE IN MOLTE APPLICAZIONI L’INGEGNERE È CHIAMATO A CONDIVIDERE CON SPECIALISTI DI ALTRI SETTORI I PROBLEMI DI:– CONNESSIONE DI SISTEMI REALIZZATI CON TECNOLOGIE ETEROGENEE

PER PORTARE A COMPIMENTO L’OBIETTIVO PREFISSATO;– SCOSTAMENTO DEL COMPORTAMENTO PREVISTO E DESIDERATO DAL

SISTEMA COMPLESSO ANCHE SE OGNI SINGOLO SOTTOSISTEMA È STATO REALIZZATO CORRETTAMENTE;

– INCREMENTO DELLA QUANTITÀ E DELLA GRAVITÀ DEI PROBLEMI DI PROGETTAZIONE E DI REALIZZAZIONE ALL’AUMENTARE DELLA COMPLESSITÀ DEL SISTEMA.

• NELLA MAGGIORANZA DEI CASI TALI PROBLEMI SONO AGGRAVATI DA:– DIFFICOLTÀ NEL DEFINIRE E DOCUMENTARE LE FINALITÀ,

FUNZIONALITÀ, PRESTAZIONI E SPECIFICHE RICHIESTE;– TENDENZA AD AFFIDARSI A METODOLOGIE EMPIRICHE E CONSOLIDATE

E A REGOLE NON SCRITTE;– PROGETTAZIONE DI INSIEME ORIENTATA A MITIGARE L’EFFETTO DI

POTENZIALI PERICOLI DETERMINATI DA ERRORI CONCETTUALI E PROCEDURALI NELLA PROGETTAZIONE DEI SINGOLI COMPONENTI.

PROBLEMI SALIENTI DELLA PROGETTAZIONE 32


APPROCCIO SISTEMATICO ALLA PROGETTAZIONE:

• METODOLOGIA CHE FAVORISCA IL RIUTILIZZO DEL KNOW-

HOW (MODEL DRIVEN DESIGN) E L’INDIVIDUAZIONE

PRECOCE DEGLI ERRORI NELLE PRIME FASI DEL PROGETTO;

• LE ATTIVITÀ DI PROGETTO DEVONO ESSERE DEFINITE

RIGOROSAMENTE:

– IDENTIFICAZIONE DELLE VARIE FASI;

– VERIFICA AL PASSAGGIO AD UNA FASE SUCCESSIVA;

– DOCUMENTAZIONE DEL LAVORO SVOLTO IN OGNI FASE.

ATTUALE SCENARIO 33


L’OBIETTIVO FINALE PUÒ ESSERE QUELLO DI CREARE UNA

LIBRERIA DI MODELLI ASTRATTI (OGNUNO ASSOCIATO ALLA

PROPRIA IMPLEMENTAZIONE HARDWARE E SOFTWARE) CHE

POSSA ESSERE UTILIZZATA PER TUTTI I NUOVI PROGETTI.

ASTRAZIONE: PRO E CONTRO 34

ALTO LIVELLO ASTRAZIONE(SPECIFICA FUNZIONALE)

BASSO LIVELLO ASTRAZIONE(SPECIFICA DI DETTAGLIO)


RIUTILIZZO PIÙ EFFICACE DEI MODELLI RIDUZIONE DEI COSTI E DEL TEMPO DI SVILUPPO

POCHISSIME DIFFERENZE MODELLO ASTRATTO ED IMPLEMENTAZIONE

MINIME VARIAZIONI NELLE SPECIFI-CHE POSSONO PORTARE AD IMPLE-MENTAZIONI MOLTO DIFFERENTI

PUÒ ESSERE CONDIVISA SOLO UNA MINIMA PARTE DEL LAVORO NECES-SARIO AD OTTENERE L’IMPLEMEN-TAZIONE FINALE

PROGETTAZIONE DI UN SISTEMA DI PRODUZIONE 35

IDENTIFICAZIONE DEIREQUISITI FUNZIONALI

PROGETTAZIONE DELLE SPECIFICHE FUNZIONALI

SEGUIRE GLI STANDARD

DOCUMENTAZIONE E VALIDAZIONE

UTENTE FINALE ESPERTI PROJECT MANAGER


COSA SONO I REQUISITI 36

REQUISITI(IEEE STANDARD GLOSSARY OF SOFTWARE ENGINEERING TEMINOLOGY)

• CONDIZIONI O CAPACITÀ DI CUI L’UTENTE HA BISOGNO PER RISOLVERE UN PROBLEMA O RAGGIUNGERE UN OBIETTIVO.

• CONDIZIONI O CAPACITÀ CHE DEVONO ESSERE RAGGIUNTI DA UN SISTEMA O DA UN SUO COMPONENTE PER SODDISFARE UN CONTRATTO, UNO STANDARD, UNA SPECIFICA O QUANTO PRESCRITTO DA OGNI ALTRO TIPO DI DOCUMENTO IMPOSTO FORMALMENTE.

• DOCUMENTAZIONE DI TALI CONDIZIONI O CAPACITÀ


ATTIVITÀ

DOCUMENTAZIONE

LA SPECIFICA DEI REQUISITI DI SISTEMA È L’ULTIMA FASE DI UNA SERIE DI ATTIVITÀAL TERMINE DI CIASCUNA DELLE QUALI VIENE PRODOTTO UN DOCUMENTO DIFFERENTE

DAI REQUISITI ALLE SPECIFICHE 37

STUDIOFATTIBILITÀ

ANALISIREQUISITI

SVILUPPOPROTOTIPO

STUDIOPROGETTO

SPECIFICAREQUISITI

RESOCONTOFATTIBILITÀ

REQUISITIUTENTE

RESOCONTOVALUTAZIONE

PROGETTOARCHITETTURA

REQUISITISISTEMA


• ELENCO DELLE ATTIVITÀ CHE IL SISTEMA DEVE SVOLGERE• DEFINIZIONE DELLE PRESTAZIONI RICHIESTE DALL’UTENTE FINALE• TRACCIABILITÀ E STORIA DEI CAMBIAMENTI• DEFINIZIONE DELLE RISORSE NECESSARIE ALLA REALIZZAZIONE

DEL PROGETTO• CONOSCENZE DI BASE PER LA PROGETTAZIONE E PER LA

OTTIMIZZAZIONE DEL PROGETTO• ORGANIZZAZIONE DELLE PROVE E DELLE METRICHE DI

VALUTAZIONE PER IL RICONOSCIMENTO DEL LAVORO SVOLTO ANCHE DURANTE LO SVILUPPO DEL PROGETTO

• DOCUMENTAZIONE DEGLI ASPETTI SALIENTI DEL SISTEMA IN TERMINI NON STRETTAMENTE TECNICI IN MODO CHE POSSA ESSERE UTILIZZATO DALLE PERSONE COINVOLTE

• ORGANIZZAZIONE CONTRATTUALE EVIDENTE E CHIARA

DOCUMENTAZIONE DEI REQUISITI 38


DOCUMENTAZIONE DEI REQUISITI

• AFFIDABILITÀ (RELIABILITY): CAPACITÀ DI UN’UNITÀ PRODUTTIVA A COMPIERE LA FUNZIONE RICHIESTA, IN CONDIZIONI STABILITE PER UN DETERMINATO INTERVALLO DI TEMPO.

• ROBUSTEZZA (ROBUSTNESS): CAPACITÀ DI UN’UNITÀ PRODUTTIVA A COMPIERE LA FUNZIONE RICHIESTA, IN CONDIZIONI FUNZIONALI CHE SI DISCOSTANO DA QUELLE STABILITE PER UN DETERMINATO INTERVALLO DI TEMPO.

• DISPONIBILITÀ (AVAILABILITY): CAPACITÀ DI UN PRODOTTO DI ESSERE IN GRADO DI ESEGUIRE LA FUNZIONE RICHIESTA NELLE CONDIZIONI IMPOSTE AD UN DETERMINATO ISTANTE OPPURE DURANTE UN DETERMINATO INTERVALLO DI TEMPO, SUPPONENDO CHE SIANO FORNITE LE RISORSE ESTERNE NECESSARIE.

• SICUREZZA (SAFETY): ASSENZA DI LIVELLI INTOLLERABILI DI RISCHIO E DI DANNO.

PROBLEMI EMERGENTIFATTORI CONSIDERATI NELLA STESURA DEI REQUISITI 39


ESEMPI DI REQUISITI

• GLOBALI (CONTEMPLANTI L’INTERO SISTEMA)

• CORRETTI (RISPONDENTI A NORME)

• COMPLETI (FRASI E TERMINI DI SENSO COMPIUTO)

• CHIARI (PRIVI DI AMBIGUITÀ)

• CONSISTENTI (NESSUN CONFLITTO FRA REQUISITI)

• MODIFICABILI (POSSIBILITÀ DI AGGIORNAMENTO)

• VERIFICABILI (CRITERI OGGETTIVI O METRICHE PRECISE)

• TRACCIABILI (IDENTIFICAZIONE UNIVOCA)

• FATTIBILI (LIMITI TEMPORALI E DI BUDGET)

• MINIMALI (NON RIDONDANZA E NECESSITÀ)

PROBLEMI EMERGENTIPROPRIETÀ DEI REQUISITI 40


PROLOGO

41

MODELLO E SIMULAZIONEDI UN SISTEMA COMPLESSO

• IL MODELLO DI UN SISTEMA È UN OGGETTO, DIVERSO DAL SISTEMA, SUL QUALE PUÒ ESSERE OPERATA UNA VERIFICA (ESPERIMENTO) AL FINE DI RISPONDERE A SPECIFICHE DOMANDE SU QUEL SISTEMA.

TIPI DI MODELLO:

• MODELLO MENTALE – IMMATERIALE (“ONESTÀ”)• MODELLO VERBALE – ESPRESSO A PAROLE• MODELLO FISICO – OGGETTO FISICO CHE IMITA IL

SISTEMA• MODELLO FORMALE – RAPPRESENTAZIONE FORMALE DI

IDEE O CONOSCENZE RELATIVE AD UN SISTEMA FINALIZZATA ALLA COMPRENSIONE, INTERPRETAZIONE, PREVISIONE E CONTROLLO DEL SISTEMA (PROTOTIPO VIRTUALE)

CONCETTO DI MODELLO 42


43PROCEDURA DI MODELLAZIONE

UN MODELLO COSTITUISCE UNA RAPPRESENTAZIONE ASTRATTA DI UN SISTEMA (FISICO O CONCETTUALE)

AFFINCHÈ UN MODELLO POSSA ESSERE VALIDO È OPPOR-TUNO CHE RISULTI: - FACILMENTE COMPRENSIBILE- AFFIDABILE- ESEGUIBILE CON UN PROGRAMMA DI CALCOLO

UN MODELLO PUÒ ESSERE DI TIPO- FUNZIONALE (PROGETTAZIONE INPUT/OUTPUT)- COMPORTAMENTALE (DINAMICO)- STRUTTURALE (REALIZZAZIONE STATICA)

È UTILIZZATO DAL PROGETTISTA COME UNO STRUMENTO PER EFFETTUARE UN PRIMA VERIFICA DELLA VALIDITÀ DELLE PROPRIE ATTIVITÀ


MODELLOFISICO

MODELLOCONCETTUALE

44

MODELLO FUNZIONALE

MODELLO DI UN SISTEMA

DESCRIZIONE PUNTUALE DELLE ATTIVITÀ E DELLE PRESTAZIONI

COSA FA IL SISTEMA IN ESAME

MODELLOCOMPORTAMENTALE

DESCRIZIONE DEL COMPORTAMENTO,DEL CONTROLLO E DELLA

TEMPORIZZAZIONE

COMEPUÒ ESSERE UTILIZZATO

MODELLOSTRUTTURALE

DESCRIZIONE IN OGGETTI, MODULIE LINEE DI COMUNICAZIONE

COMEÈ STATO REALIZZATO


45MODELLO DI UN SISTEMA

DIAGRAMMADEI CASI

D’USO

DIAGRAMMADELLE

SEQUENZE

DIAGRAMMADEGLI STATI

DIAGRAMMADEI

COMPONENTI

DIAGRAMMADELLECLASSI

DIAGRAMMADEGLI

OGGETTI

DIAGRAMMADELLE

DISTRIBUZIONI

MODELLODELLA FUNZIONALITÀ

MODELLODELLA STRUTTURA

MODELLODEL SISTEMA COMPLESSO

MODELLODEL COMPORTAMENTO

DIAGRAMMADELLE

COLLABORAZIONI

DIAGRAMMADELLE

ATTIVITÀ


• LA SIMULAZIONE È UN ESPERIMENTO OPERATO SU UN MODELLO

• MOTIVAZIONI:– ESPERIMENTI SUL SISTEMA REALE COSTOSI O

PERICOLOSI– SISTEMA REALE NON DISPONIBILE– GRANDEZZE FISICHE NON COMPATIBILI CON

QUELLE DELLO SPERIMENTATORE (AD. ES. DURATA DELL’ESPERIMENTO)

– VARIABILI INACCESSIBILI– FACILE MANIPOLAZIONE DEI MODELLI– SOPPRESSIONE DEI DISTURBI

46SIGNIFICATO DI SIMULAZIONE


• RIDURRE I COSTI DI PROGETTAZIONE, ATTRAVERSO MODELLI INDIPENDENTI DAL SISTEMA OPERATIVO E DALL’HARDWARE

• RIDURRE I COSTI DELL’HARDWARE E DELLE TECNOLOGIE UTILIZZATI NEI SISTEMI DI CONTROLLO

• OMOGENEIZZARE LE CONOSCENZE DEI VARI TECNICI COINVOLTI NELLA PROGETTAZIONE E RIDURRE I COSTI DI ADDESTRAMENTO DEL PERSONALE

• UNIFORMARE LE RAPPRESENTAZIONI DI TUTTI I COMPONENTI DEL SISTEMA DI CONTROLLO

• DEFINIRE LE INTERFACCE STANDARD PER LA COMUNICAZIONE TRA I COMPONENTI DEL SISTEMA

OLTRE A FORNIRE IL MODELLO DI ARCHITETTURA COMPLETA PER IL SISTEMA IN ESAME, LA METODOLOGIA RAPPRESENTA ANCHE UN IMPORTANTE PARADIGMA PROGETTUALE, CHE CONSENTE DI:

47RUOLO DELLA SIMULAZIONE


48MODELLI E SIMULAZIONE: PERICOLI

• INNAMORARSI DEL MODELLO: DIMENTICARE CHE IL MODELLO NON APPARTIENE AL MONDO REALE

• FORZARE LA REALTÀ AD AVERE LO STESSO COMPORTA-MENTO DEL MODELLO

• DIMENTICARE IL LIVELLO DI ACCURATEZZA DEL MODELLO: SEMPLIFICARE TROPPO LE PREMESSE


FORMULAZIONE

ESPERTI DI DOMINIO

CONSISTENZA

MODELLO

CONSISTENZA

IMPLEMENTAZIONE

VALIDAZIONE

VALIDAZIONEVALIDAZIONE

VERIFICA

CONSISTENZAALTRO MODELLO

VERIFICAINFORMALE

VERIFICAFORMALE

49RUOLO DEL MODELLO NELLA PROGETTAZIONE


VINCOLI FORMALI

PROVE

ESPERTO DI DOMINIO

ADDETTO ALLA VERIFICA

MODELLODEI REQUISITI

LINGUAGGIO DIMODELLAZIONEDEI REQUISITI

50VERIFICA DI UN MODELLO

STRUMENTO DI SUPPORTO PERLA VERIFICA DI UN MODELLO


PROLOGO

51

UNIFIED MODELLING LANGUAGE

IL LINGUAGGIO UML 52

IL LINGUAGGIO UMLLINGUAGGIO FORMALE UTILE A RAPPRESENTARE

STRUTTURA DEL LINGUAGGIO UML

INSIEME SELEZIONATO DI SIMBOLI GRAFICI PER SVILUPPARE I VARI MODELLI

GLI ASPETTI DI MAGGIORE INTERESSE MEDIANTE MODELLI STANDARD

IN FORMA GRAFICA • PROGRAMMI SOFTWARE, • REALIZZAZIONI HARDWARE,• SISTEMI ORGANIZZATIVI

UML

POSSIBILITÀ ESPANDERE LA CAPACITÀ DI RAPPRESENTAZIONE DEI SINGOLI MODELLI

RACCOLTA DI MODELLI GRAFICI PER RAPPRESENTARE GLI ASPETTI SIGNIFICATIVI COLLEGATI ALLA STRUTTURA E ALLE CONDIZIONI OPERATIVE DEI VARI MODELLI

VARI SOFTWARE DI SUPPORTO DISPONIBILI IN RETE


IL LINGUAGGIO UML 53

IL LINGUAGGIO UML

• NON PROPRIETARIO• IMPIEGA POCHI SIMBOLI STANDARDIZZATI• UTILE AL FORWARD & REVERSE ENGINEERING• OBJECT ORIENTED• PERMETTE DI DESCRIVERE DETTAGLIATAMENTE

UN SISTEMA PER QUANTO RIGUARDA:LA STRUTTURALA MODALITÀ DI FUNZIONAMENTO I COLLEGAMENTI CON L’ESTERNO (INTERFACCE)


MOTIVAZIONE DELLA RAPPRESENTAZIONE AD OGGETTI 54

PERCHÉ ORIENTATO AGLI OGGETTI ?

• È IN GRADO DI DOMINARE LA COMPLESSITÀ E L’ETEROGENEITÀ DEI SISTEMI COMPLESSI

• MASSIMIZZA:LA PORTABILITÀLA PERSONALIZZABILITÀLA MODULARITÀLA RIUSABILITÀ

UN OGGETTO UML MOSTRA:• L’UTILIZZAZIONE• IL FUNZIONAMENTO• LA REALIZZAZIONE• LA MANUTENZIONE• LA QUALITÀ• L’UBICAZIONE


MODELLI PER LA PROGETTAZIONE 55

MODELLI UTILIZZATI PER LA PROGETTAZIONE

• MODELLI DI UTILIZZAZIONEFUNZIONALITÀ E PRESTAZIONI OFFERTE ALL’ UTILIZZATORE• MODELLI DI APPLICAZIONEMODELLO DI UNO SISTEMA APPLICATO AD UNO SPECIFICO

SCENARIO APPLICATIVO• MODELLI SECONDO BLOCCHI FUNZIONALIMODELLO DEL SISTEMA, SUDDIVISO IN BLOCCHI FUNZIONALI COMUNICANTI.• MODELLI DI UNA RISORSAMODELLO DI UN ELEMENTO SINGOLO• MODELLI DI UN DISPOSITIVOMODELLO DI DISPOSITIVO/APPARATO/IMPIANTO


DIAGRAMMI UML 56

LE SOLUZIONI OFFERTE DALL’UML:

• COMUNICAZIONE CON L’ ESTERNO– DIAGRAMMA DEI CASI D’USO – DIAGRAMMA DELLE COLLABORAZIONI

• STRUTTURA DEL SISTEMA– DIAGRAMMA DELLE CLASSI – DIAGRAMMA DEGLI OGGETTI– DIAGRAMMA DEI COMPONENTI– DIAGRAMMA DELLE DISTRIBUZIONI

• FUNZIONAMENTO– DIAGRAMMA DEGLI STATI– DIAGRAMMA DELLE ATTIVITÀ– DIAGRAMMA DELLE SEQUENZE


USO DEI DIAGRAMMI 57

ESEMPIO D’USO DEI DIAGRAMMI UML1 DEFINIZIONE DELLE ATTIVITÀ: ATTRAVERSO COLLOQUI CON

L’UTILIZZATORE VENGONO ANALIZZATE IN MODO DETTAGLIATO LE ATTIVITÀ FONDAMENTALI DEL SISTEMA, DEFINENDO UN DIAGRAMMA DELLE ATTIVITÀ

5 COMPRENSIONE DELL’UTILIZZO DEL SISTEMA: ATTRAVERSO COLLOQUI CON I POTENZIALI UTENTI VENGONO DEFINITI GLI ATTORI E I RELATIVI CASI D’ USO, PER REALIZZARE UN DIAGRAMMA DEI CASI D’USO

4 PRESENTAZIONE DEI RISULTATI: TERMINATA LA RACCOLTA DELLE INFORMAZIONI VENGONO PRESENTATI I RISULTATI DELLE ANALISI ALL’UTILIZZATORE

3 CORRELAZIONE TRA I SISTEMI: VENGONO IDENTIFICATE LE RELAZIONI DI DIPENDENZA TRA I VARI SISTEMI ATTRAVERSO LA REALIZZAZIONE DI UN DIAGRAMMA DI DISTRIBUZIONE

2 ANALISI DEL SISTEMA: VENGONO DEFINITI GLI ATTRIBUTI E LE OPERAZIONI DELLE CLASSI DI ELEMENTI CHE COMPONGONO IL SISTEMA, PER REALIZZARE UN DIAGRAMMA DELLE CLASSI



IL LINGUAGGIO UML

6 ANALISI DELLE TRANSIZIONI DI STATO: DURANTE LA CREAZIONE DEI MODELLI VENGONO ANALIZZATE LE EVENTUALI TRANSIZIONI DI STATO DI OGNI OGGETTO, REALIZZANDO UN DIAGRAMMA DI STATO

10 DEFINIZIONE DEI COMPONENTI: VENGONO VISUALIZZATI I COMPONENTI DEL SISTEMA E LE LORO DIPENDENZE, REALIZZANDO UN DIAGRAMMA DEI COMPONENTI

9 DEFINIZIONE DEGLI OGGETTI: DAL DIAGRAMMA DELLE CLASSI SI DERIVA UNA ISTANZA DEL SISTEMA: DIAGRAMMA DEGLI OGGETTI

8 ANALISI DELL’INTEGRAZIONE DEL SISTEMA CON SISTEMI PREESISTENTI: SI RAFFINA IL DIAGRAMMA DI DISTRIBUZIONE PER DEFINIRE L’ INTEGRAZIONE CON I SISTEMI PREESISTENTI O CON ALTRI SISTEMI CON I QUALI È NECESSARIO COOPERARE

7 INTERAZIONE TRA GLI OGGETTI: PER METTERE IN RELAZIONE GLI OGGETTI, DEFINITI NEI PRECEDENTI DIAGRAMMI, CON LE TRANSIZIONI DI STATO, SI REALIZZANO IL DIAGRAMMA DI SEQUENZA ED IL DIAGRAMMA DI COLLABORAZIONE



IL LINGUAGGIO UML

11 REALIZZAZIONE DEL CODICE: CON IL DIAGRAMMA DELLE CLASSI, IL DIAGRAMMA DEGLI OGGETTI, IL DIAGRAMMA DELLE ATTIVITÀ ED IL DIAGRAMMA DEI COMPONENTI A DISPOSIZIONE, VIENE REALIZZATO DAI PROGRAMMATORI IL CODICE PER IL SISTEMA

15 PROVE SUL SISTEMA INSTALLATO

14 INSTALLAZIONE DEL SISTEMA COMPLETO SULL’ HARDWARE APPROPRIATO

13 COSTRUZIONE DELL’ INTERFACCIA UTENTE E COLLEGAMENTO AL CODICE: UNA VOLTA CHE È A DISPOSIZIONE IL SISTEMA FUNZIONANTE E COMPLETO CON L’ INTERFACCIA UTENTE

12 PROVE DEL CODICE


DIAGRAMMA DELLE ATTIVITÀ 60

DIAGRAMMA DELLE ATTIVITÀUTILE PER:• MODELLARE E SINCRONIZZARE

LE ATTIVITÀ SVOLTE DAL SISTEMA

• INDICARE LE VARIABILI DI ATTIVAZIONE

• LE ATTIVITÀ SONO ORDINATE VERTICALMENTE IN BASE ALL’OG-GETTO CHE HA LA RESPONSABI-LITÀ DI PORTARLE AVANTI (LINEE DI DIVISIONE = SWIMLINES)

UTILIZZA BARRE DI SINCRONIZ-ZAZIONE E BLOCCHI LOGICO-DECISIONALI PER VISUALIZZARE IL FLUSSO DELLE INFORMAZIONI

USA I FORK/JOIN PER I PROCESSI PARALLELI: UN JOIN SI SUPERA SOLO QUANDO TUTTI I PROCESSI CHE VI CONFLUISCONO SONO PRONTI

ATTIVITÀ 4

ATTIVITÀ 2 ATTIVITÀ 3?

ATTIVITÀ 1

SINO

FORK

JOIN

BARRA DI SINCRONIZZAZIONEPERCORSO

DECISIONALE

PERCORSICONCORRENTI

TRANSIZIONE

ATTIVITÀ


DIAGRAMMA DELLE CLASSI 61

DIAGRAMMA DELLE CLASSI• DESCRIZIONE ORIENTATA AGLI

OGGETTI DEL SISTEMA

• OGNI CLASSE È CARATTERIZZATA DA NOME/ATTRIBUTI/OPERAZIONI

• PER OGNI ATTRIBUTO ED OPERAZIONE VIENE INDICATO IL LIVELLO DI ACCESSO PUBBLICO / PROTETTO / PRIVATO

• LE CLASSI SONO COLLEGATE TRA LORO TRAMITE LE “ASSOCIAZIONI” E LA “MOLTEPLICITÀ DELLE ASSOCIAZIONI”

• NON VIENE FATTO RIFERIMENTO AGLI EVENTI DI SINCRONIZZAZIO-NE MA SOLO ALLA STRUTTURA

• OGNI CLASSE È INOLTRE CORREDATA DA UNA SPECIFICA DI FUNZIONALITÀ, DI PRESTAZIONI, DI FUNZIONAMENTO NORMALE (SCHEMA DI BASE), DI FUNZIONA-MENTO ANOMALO (ESTENSIONI).

POSSIBILI ASSOCIAZIONI

٭ …00…1

٭… 1

0…y x…1y …٭

٭ …00…1

٭… 1

0…y x…1y …٭

CLASSE 1

ATTRIBUTI

ASSOCIAZIONI

NOME

OGGETTO 1 OGGETTO 2

CLASSE 2

ATTRIBUTI

ASSOCIAZIONI

NOME

ASSOCIAZIONE

AGGREGAZIONE

COMPOSIZIONE

REALIZZAZIONE

EREDITARIETÀ


DIAGRAMMA DELLE DISTRIBUZIONI 62

DIAGRAMMA DELLE DISTRIBUZIONI• MOSTRA LA MACRO-ARCHITETTURA

DI PIÙ SISTEMI COLLEGATI.

• L’ELEMENTO CHIAVE, UNA RISORSA FISICA, È IL NODO RAPPRESENTATO DA UN PARALLELEPIPEDO

• UN NODO PUÒ AVERE CAPACITÀ DI ELABORAZIONE O FUNGERE SOLO DA COLLEGAMENTO CON UNA INTERFACCIA

• I NODI SONO IN GENERE COLLEGATI DA ASSOCIAZIONI RAPPRESENTANTI UN LINK FISICO

NOME NOME

CONNESSIONE TRA NODI

NODO


DIAGRAMMA DEI CASI D’USO 63

DIAGRAMMA DEI CASI D’USO

• INTERAZIONI TRA SISTEMA ED ENTITÀ ESTERNE, CIOÈ GLI

UTILIZZATORI, DETTI «ATTORI»

• NELLO SCHEMA SI HA: L’UTENTE/DISPOSITIVO X CHE PUÒ

UTILIZZARE IL SISTEMA NEL MODO (CASO D’USO) Y

• SI UTILIZZANO ASSOCIAZIONI O GENERALIZZAZIONI

ATTORE X CASO D’USO Y


DIAGRAMMA DEGLI STATI 64

DIAGRAMMA DEGLI STATI

• METTE IN RILIEVO LA SEQUENZA DI ATTIVAZIONE DEI VARI OGGETTI, NONCHÉ LO STATO INIZIALE E FINALE

• MOSTRA LE CONDIZIONI CHE IMPLICANO UN PASSAGGIO DI STATO

• È IN GRADO DI MOSTRARE ATTIVITÀ PARALLELE

• SI BASA SUL CONCETTO DI EVENTO

NOME 2

VARIABILI CARATTERIZZANTI

LO STATO

ATTIVITÀ

STATO FINALE

NOME 2

VARIABILI CARATTERIZZANTI

LO STATO

ATTIVITÀ

STATO INIZIALE

E[C]/AEVENTO / CONDIZIONE / AZIONE


DIAGRAMMA DELLE SEQUENZE 65

DIAGRAMMA DELLE SEQUENZE

• SEQUENZA TEMPORALE DEI MESSAGGI SCAMBIATI TRA I VARI OGGETTI COMPONENTI IL SISTEMA

• L’ASSE VERTICALE RAPPRESENTA IL TEMPO (TIMELINE)

• L’ASSE ORIZZONTALE GLI OGGETTI E GLI ATTORI

• POSSONO ESSERE QUINDI RAPPRE-SENTATE ANCHE LE DURATE DI OGNI SINGOLA ATTIVITÀ ED ITERAZIONE

MESSAGGIO DI CHIMATAAD UN ALTRO OGGETTO

MESSAGGIO DI RISPOSTAAD UN ALTRO OGGETTO

MESSAGGIO ASINCRONO

MESSAGGIO DI CHIMATAALLO STESSO OGGETTO

MESSAGGIORICORSIVO

ATTIVITÀDELL’OGGETTO

MESSAGGIO

OGGETTOATTORE


DIAGRAMMA DELLE COLLABORAZIONI 66

DIAGRAMMA DELLE COLLABORAZIONI

• MOSTRA LA STRUTTURA INFORMATIVA CON CUI I VARI OGGETTI ED ATTORI COMUNICANO TRA DI LORO

• NON RAPPRESENTA LA CRONOLOGIA DI TALE COMUNICAZIONE

• SUI LINK VANNO INDICATI I MESSAGGI SCAMBIATI PER OGNI AZIONE

ATTORE

MESSAGGIO

OGGETTO

AZIONE 1 AZIONE 3

AZIONE 2

NOME 1

NOME 2

NOME 3


DOCUMENTAZIONE DEL SOFTWARE DI CONTROLLO 67

DIAGRAMMA DEGLI OGGETTI

A PARTIRE DAL DIAGRAMMA DELLE CLASSI SI DERIVANO LE

SINGOLE ISTANZE DEGLI OGGETTI CHE COSTITUISCONO IL

SISTEMA (AD ES. DALLA CLASSE «MOTORI CC» SI POSSONO

ISTANZIARE TUTTI I MOTORI IN CORRENTE CONTINUA PRESENTI

NELL’IMPIANTO).

CLASSE

ATTRIBUTI

OPERAZIONI

OGGETTO 1 OGGETTO 2

CLASSE

ATTRIBUTI

OPERAZIONI

CLASSE

ATTRIBUTODELLA

ASSOCIAZIONE

OPERAZZIONI

OGGETTO 3


DIAGRAMMA DEI COMPONENTI 68

DIAGRAMMA DEI COMPONENTI

• FORNISCE UNA VISIONE STRUTTURALE DEL SISTEMA FUNZIONANTE• I COMPONENTI SONO INSIEMI DI OGGETTI RAGGRUPPATI PER

FUNZIONALITÀ IN COMPONENTI, DISPOSITIVI/APPARATI E IMPIANTI/SOTTOSISTEMI

• MOSTRA IN PARTICOLARE I COLLEGAMENTI TRA COMPONENTI

[NOME PACKAGE]NOME

COMPONENTE 1

[NOME PACKAGE]NOME

COMPONENTE 3

[NOME PACKAGE]NOME

COMPONENTE 2

COMPONENTE

RELAZIONE DI DIPENDENZA


LO STANDARD DI PROGETTAZIONE ESA-PSS05 69

LO STANDARD DI PROGETTAZIONE ESA-PSS05• SI TRATTA DI UNA SERIE DI NORME STANDARD DI SVILUPPO E DI INGEGNERIA

DEL SOFTWARE• ORIGINARIAMENTE ERA STATO SVILUPPATO PER I SOLI PRODOTTI

SOFTWARE DELL’AGENZIA SPAZIALE EUROPEA (ESA)• OGGI È LARGAMENTE UTILIZZATO ANCHE DALLE COMPAGNIE PRIVATE• PERMETTE UNA GESTIONE ED UN CONTROLLO COMPLETO E FUNZIONALE DI

TUTTE LE FASI DI SVILUPPO• REGOLAMENTA LA PROGETTAZIONE DI TUTTI I COMPONENTI E DI TUTTE LE

INTERFACCE DEL SISTEMA SOFTWARE


• Guide to applying the ESA Software Engineering Standards to small software projects;• Guide to the Software Engineering Standards• Guide to the user requirements definition phase• Guide to the software requirements definition phase• Guide to the software architectural design phase• Guide to the software detailed design and production phase• Guide to the software transfer phase• Guide to the software operations and maintenance phase• Guide to software project management• Guide to software configuration management• Guide to software verification and validation• Guide to software quality assurance

LO STANDARD DI PROGETTAZIONE ESA-PSS05 - GUIDE 70

LO STANDARD DI PROGETTAZIONE ESA-PSS05PROGETTAZIONE DI UN SISTEMA COMPLESSO

NORMATIVA ESA PER LA PROGETTAZIONE 71

FASE 1: REQUIREMENTS CAPTURE PROCESS

LA NORMATIVA ESA SI ARTICOLA NELLA SEGUENTI FASI:

FASE 2: ANALYSIS & DESIGN

FASE 3: REALIZZAZIONE E PROVE PER LA VALIDAZIONE


INDIVIDUAZIONE DEI REQUISITI 72

FASE 1: REQUIREMENTS CAPTURE PROCESS

• INFORMAZIONI SU STRUTTURA E FUNZIONAMENTO

• INFORMAZIONI SULL’ INTEGRAZIONE CON SISTEMI GIÀ ESISTENTI

• INFORMAZIONI SULLE PRESTAZIONI DESIDERATE

• INFORMAZIONI SULLA QUALITÀ DESIDERATA

• INFORMAZIONI SUI TEMPI DI CONSEGNA

• INFORMAZIONI SUI MOMENTI E SULLE MODALITÀ DI VERIFICA


ANALISI E PROGETTAZIONE 73

FASE 2: ANALYSIS & DESIGN1) DEFINIZIONE ATTIVITÀ (ACTIVITY DIAGRAM)

2) ANALISI DEL SISTEMA (CLASS DIAGRAM)

3) COMPRENSIONE DELL’UTILIZZO (USE CASES DIAGRAM)

4) ANALISI TRANSIZIONI DI STATO (STATE CHART DIAGRAM)

5) INTERAZIONE TRA OGGETTI (SEQUENCE&COLLABORATION DIAGRAM)

6) INTEGRAZIONE CON SISTEMI PRE-ESISTENTI (DISTRIBUTION DIAGRAM)

7) DEFINIZIONE SINGOLI ELEMENTI (OBJECTS DIAGRAM)

8) DEFINIZIONE DEI COMPONENTI (COMPONENT DIAGRAM)

IN OGNI FASE NON BISOGNA MAI PERDERE IL CONTATTO CON IL CLIENTE! RELAZIONI & VERIFICHE (DOCUMENTATE!!!)


REALIZZAZIONE E PROVE DI VALIDAZIONE 74

FASE 3:REALIZAZIONE E PROVE PER LA VALIDAZIONE

QUESTE FASI COMPRENDONO:

- LA REALIZZAZIONE DEI SINGOLI SISTEMI

- LE PROVE SINGOLE DEI SISTEMI REALIZZATI

- L’INTEGRAZIONE TRA DI LORO E CON SISTEMI ESISTENTI

- LE PROVE INTEGRATE, PER VERIFICARE IL FUNZIONAMENTO DEL SISTEMA COMPLESSIVO


PROCEDURA SISTEMATICA DI PROGETTAZIONE 75

DEFINIZIONEDELLE FINALITÀE DELLE PRESTAZIONI

MODELLO FUNZIONALEDELLA NUOVA REALIZZAZIONE

ARCHITETTURA DELLA NUOVA REALIZZAZIONE

REALTÀ VIRTUALEDELLA NUOVA REALIZZAZIONE

REALIZZAZIONE DELLE PARTI IN SOFTWARE

REALIZZAZIONE DELLE PARTI IN HARDWARE

INTEGRAZIONE DELLE PARTI HARDWARE E SOFTWARE

PROVE DI FUNZIONALITÀ

INTEGRAZIONE IN SOTTOSISTEMI


INTEGRAZIONEDELLA NUOVA REALIZZAZIONE


ACCETTAZIONE

MESSA IN ESERCIZIO


SOFTWARE

INGEGNERIA

DI SIS

TEAMA

76DOCUMENTAZIONE DELLA PROGETTAZIONE

UMLDIAGRAMMA DEI CASI D’USO

UMLDIAGRAMMA

DEI COMPONENTI

DEFINIZIONEDELLE FINALITÀE DELLE PRESTAZIONI

MODELLO FUNZIONALEDELLA NUOVA REALIZZAZIONE

ARCHITETTURA DELLA NUOVA REALIZZAZIONE

REALTÀ VIRTUALEDELLA NUOVA REALIZZAZIONE

REALIZZAZIONE DELLE PARTI IN SOFTWARE

REALIZZAZIONE DELLE PARTI IN HARDWARE

INTEGRAZIONE DELLE PARTI HARDWARE E SOFTWARE


INTEGRAZIONE IN SOTTOSISTEMI


INTEGRAZIONEDELLA NUOVA REALIZZAZIONE


ACCETTAZIONE

MESSA IN ESERCIZIO

UMLDIAGRAMMA DELLE ATTIVITÀ

UMLDIAGRAMMA DEGLI STATI

UMLDIAGRAMMA DELLE CLASSI

UMLDIAGRAMMA

DELLE DISTRIBUZIONI

UMLDIAGRAMMA DELLE COLLABORAZIONI

UMLDIAGRAMMA

DEGLI OGGETTI

UMLDIAGRAMMADELLE SEQUENZE


LIVELLO FISICOLIVELLO CONCETTUALE

PUNTI DI VISTA

MODELLAZIONE UML

77

PROGETTAZIONE

INGEGNERE DI SISTEMA

PRESTAZIONICOMPORTAMENTO

REQUISITI FUNZIONALI UTILIZZAZIONE

UTENTE FINALE

FUNZIONALITÀ

PROGRAMMI PER

LA GESTIONE

REALIZZAZIONE

CASO D’USOUNA APPLICAZIONE

VISTA DALL’UTENTE

IL FUNZIONAMENTO

INTEGRATORE DI SISTEMAINSTALLAZIONE

COLLAUDO


INGEGNERE GESTIONALE

PANNELLO DI CONTROLLO

COMANDO POSIZIONE

SLITTA

COMANDO MOVIMENTO

TRAPANO

ESEMPIO DI APPARATO 78

APPROCCIO OBJECT ORIENTED

DISPOSITIVO DI CONTROLLO

SLITTA


TRAPANO

RETE DI COMUNICAZIONETRA I DISPOSITIVI

DI CONTROLLO


FASI DELLA LAVORAZIONE 79


LA LAVORAZIONE PUÒ INIZIARE

IL PEZZO È CARICATO SULLA SLITTA

IL PEZZO È PORTATOSOTTO IL TRAPANO

IL TRAPANO PUÒ INIZIARE LA LAVORAZIONE

IL TRAPANO EFFETTUA LA LAVORAZIONE

IL TRAPANO HA CONCLUSO LA LAVORAZIONE

IL TRAPANO È ALLONTANATO DAL PEZZO

IL PEZZO È SCARICATO DALLA SLITTA

LA LAVORAZIONE È CONCLUSA




CICLO DI LAVOROMOVIMENTO

PEZZO1. IL PEZZO DA LAVORARE VIENE

POSIZIONATO SULLA SLITTA

MOVIMENTO SLITTA

2. LA SLITTA VIENE POSIZIONATA SOTTO IL TRAPANO

MOVIMENTO TRAPANO

3. VIENE ABBASSATO IL TRAPANO

MOVIMENTO TRAPANO

5. TERMINATA LA LAVORAZIONE, IL TRAPANO VIENE SOLLEVATO

MOVIMENTO SLITTA

6. ILTRAPANO VIENE FERMATO

LAVORAZIONE 4. VIENE AVVIATA LA LAVORAZIONE

7. VIENE MOVIMENTATA LA SLITTA PER SCARICARE IL PEZZO

MOVIMENTO PEZZO

INIZIO CICLO

FINE CICLO


PANNELLO DI CONTROLLO

COMANDO POSIZIONE

SLITTA

COMANDO MOVIMENTO

TRAPANO

MOVIMENTOPEZZO

MOVIMENTOTRAPANO




SLITTA


TRAPANO

BASSO

PRONTO

CARICA

ATTESA

ALTO

CO

MU

NIC

AZ

ION

E D

AT

I

SENSORI

COMUNICAZIONE DATI

SENSORI

RETE DI COMUNICAZIONETRA I DISPOSITIVI

DI CONTROLLO


UNITA’ DI FORATURA AUTOMATICA

DIAGRAMMA DEI CASI D’USO 82

ESEMPIO MODELLAZIONE UML

LAVORAZIONENORMALE FUNZIONAMENTO

OPERATORE/IMPIANTO

CONTROLLOTRAPANO

CONTROLLOSLITTA

<<INCLUDE>>

<<INCLUDE>>

PROGETTISTA

SETUP

<<INCLUDE>>

<<INCLUDE>> <<INCLUDE>>

<<INCLUDE>>

OPERATOREOPERATORE

ARRESTASISTEMA

RIAVVIASISTEMA

GESTIONEALLARMI

MANUTENZIONE


È COMPOSTA DA

È C

OM

PO

ST A

DAÈ C

OMPOSTA DA



CONTROLLORE

- ATTESA - CONTROLLO

+ INVIA SEGNALE () + RICEVE SEGNALE ()

TRAPANO

- POSIZIONE - OPERATIVITÀ

+ TRASLA () + RUOTA ()

SLITTA

- POSIZIONE - OPERATIVITÀ

+ TRASLA () + RUOTA ()

UNITÀ DI FORATURA

+ ESEGUI LAVORAZIONE ()

CO

LL

AB

OR

A C

ON

CO

LL

AB

OR

A C

ON



ESEMPIO MODELLAZIONE UMLPROGETTAZIONE DI UN SISTEMA COMPLESSO

DIAGRAMMA DEGLI OGGETTI 85


CONTROLLO TRAPANO

CONTROLLO SLITTA

TRAPANO SLITTA

UNITÀ DI FORATURA


CONTROLLOSLITTA

SLITTACONTROLLO

TRAPANOTRAPANO

1: INIZIA 2: CARICA PEZZO

3: CARICATO

4: A SINISTRA

5: PRONTO

9: ABBASSA

10: LAVORAZIONE

8: AVVIARE TRAPANO

6: PEZZO IN POSIZIONE

7: INIZIO CICLO DI LAVORAZIONE ?

DIAGRAMMA DELLE SEQUENZE

OPERATORE

86


DIAGRAMMA DELLE SEQUENZE 87

CONTROLLOSLITTA

SLITTA

11: SOLLEVA

12 : IN ALTO

OPERATORE

13: FINE LAVORAZIONE

14: A DESTRA

15 : IN ATTESA

16 : SCARICA

17 : SCARICATO

18: FINITO

TRAPANOCONTROLLO

TRAPANO

APPROCCIO OBJECT ORIENTEDESEMPIO MODELLAZIONE UMLPROGETTAZIONE DI UN SISTEMA COMPLESSO

LAVORAZIONE

DIAGRAMMA DI STATO 88

APPROCCIO OBJECT ORIENTEDESEMPIO MODELLAZIONE UML

SLITTA IN ATTESA

SCARICA

SLITTA IN ATTESA CARICA

INIZIO

FINE

CICLO TRAPANO

SLITTA IN PRONTO

TRAPANO ALTO

FERMO

TRAPANO ALTO

ROTAZIONE

TRAPANO BASSO

LAVORAZIONE


DIAGRAMMA DELLE ATTIVITA’ 89

SLITTA TRAPANO

AZIONACOMANDO SLITTA

LAVORAZIONE

TRAPANO IN BASSO

CARICAMENTOPEZZO

SLITTA ASINISTRA

AVVIAMENTOTRAPANO

AZIONA COMANDO TRAPANO

INIZIO CICLO


OPERATORE



TRAPANO INALTO

TRAPANO FERMO

SLITTA A DESTRA

SCARICA IL PEZZO

FINE CICLO

DIAGRAMMA DELLE ATTIVITA’ 90


OPERATORE SLITTA TRAPANO


DIAGRAMMA DI DISTRIBUZIONE 91

NODO 1

CONTROLLO

SLITTA

SLITTA

NODO 2

CONTROLLO

TRAPANO

TRAPANO

RETE DI COMUNICAZIONE

DATI

ESEMPIO MODELLAZIONE UMLPROGETTAZIONE DI UN SISTEMA COMPLESSO

UML IN SINTESI

MODELLAZIONE UML

UML IN SINTESI

UML È COMPLESSO E VA ADATTATO ALLE ESIGENZE DEI PROGETTISTI E AL CONTESTO DEL PROGETTO PRENDENDO IN CONSIDERAZIONE I SEGUENTI FATTORI:

SETTORE DI ATTIVITÀ

TIPOLOGIA DI PROGETTO

ESIGENZE DI CONFORMITÀ A NORME

COMUNICAZIONE CON COMMITTENTI E FORNITORI

COMPOSIZIONE E DISTRIBUZIONE DEL GRUPPO DI LAVORO

92


UML IN SINTESI 93

UML IN SINTESI

UML NON SUGGERISCE NÉ PRESCRIVE UNA SEQUENZA DI REALIZZAZIONE DEI DIVERSI DIAGRAMMI

UML OFFRE UN’AMPIA GAMMA DI POSSIBILI MODALITÀ DI UTILIZZO TRA LE QUALI I PROGETTISTI SONO LIBERI DI SCEGLIERE

NON TUTTI I DIAGRAMMI SONO UGUALMENTE UTILI IN OGNI CIRCOSTANZA

IN OGNI APPLICAZIONE BISOGNA INDIVIDUARE QUALI DIAGRAMMI SONO EFFETTIVAMENTE NECESSARI PER LA REALIZZAZIONE DEL MODELLO

MODELLAZIONE UMLPROGETTAZIONE DI UN SISTEMA COMPLESSO

CONCLUSIONI 94

LE METODOLOGIE DI PROGETTO ORIENTATE AGLI OGGETTI SONO STATE ADOTTATE CON SUCCESSO NELL’AUTOMAZIONE INDUSTRIALE PER FAR FRONTE ALLE SEGUENTI ESIGENZE:

CONCLUSIONI

• RIDURRE I TEMPI CHE INTERCORRONO TRA LA PROGETTAZIONE E LA REALIZZAZIONE DI UN SISTEMA

• SVILUPPARE ARCHITETTURE SOFTWARE AD OGGETTI, CHE OFFRONO MAGGIORI POSSIBILITÀ DI INTEGRAZIONE TRA SISTEMI ETEROGENEI

• REALIZZARE SISTEMI DI PRODUZIONE, IMPIANTI ED APPARATI CON STRUTTURE MODULARI CHE PERMETTONO:

UNA SEMPLICE CONFIGURAZIONE DEL SISTEMA

UNA MANUTENZIONE PIÙ RAPIDA ED ECONOMICA

LA POSSIBILITÀ DI RICONFIGURAZIONE

LA POSSIBILITÀ DI INSERIMENTO DI NUOVE UNITÀ


CONCLUSIONI 95

L’ ESISTENZA DEGLI STANDARD IEC E ISA FORNISCE LE LINEE GUIDA PER LA PROGETTAZIONE DI ARCHITETTURE SOFTWARE ORIENTATE AGLI OGGETTI

PROGETTARE SISTEMI CON STRUTTURA NON CONFORME AGLI STANDARD SI RIVELA UN APPROCCIO PERDENTE, PERCHÈ PORTA ALLA REALIZZAZIONE DI SOLUZIONI PROPRIETARIE SENZA POSSIBILITÀ DI INTEGRAZIONE CON ALTRI SISTEMI E NON RIUTILIZZABILI, QUINDI PIÙ COSTOSE


Dipartimento di Informatica e Sistemistica Procedure di Progettazione e di Documentazione per il...

Documents

Transcript of Dipartimento di Informatica e Sistemistica Procedure di Progettazione e di Documentazione per il...