2. INGEGNERIA DI SISTEMA

Testo completo

(1)2. INGEGNERIA DI SISTEMA T Il software è inutile a meno che non sia combinato con componenti hardware per formare un “sistema”. T Introdurremo il concetto di ingegneria di sistema T Descriveremo il processo di acquisizione e di T T. sviluppo di un sistema Vedremo come rappresentare l’architettura di un sistema Introdurremo il concetto di affidabilità di un sistema. Ingegneria di sistema T. T. Un sistema è un insieme di componenti correlate T Software T Hardware T Risorse umane T Dati (Informazione) che insieme realizzano un obiettivo comune Ingegneria di sistema significa: T Progettare T Implementare T Installare sistemi che includono hardware (meccanico, elettrico, elettronico), software e personale.

(2) Il tutto non è la somma delle parti T Le componenti di un sistema possono operare in. modo indipendente, ma quando sono integrate in un sistema dipendono da altre componenti T Esempi T Una penna T Un sistema di gestione del traffico aereo T Un sistema di allarme. Affidabilità di un sistema T L’interdipendenza delle componenti fa sì che gli. T T. errori possano essere propagati in tutto il sistema. I fallimenti possono essere dovuti a interrelazioni tra componenti di cui non si è tenuto conto L’affidabilità dipende dall’affidabilità dell’hardware, del software e degli operatori Resilience (capacità di recupero) = abilità del sistema di continuare ad operare correttamente in presenza di fallimenti di una o più componenti.

(3) Proprietà emergenti T Proprietà del sistema visto globalmente, che non T T. necessariamente possono essere derivate dalle proprietà delle singole componenti del sistema Possono essere conseguenza delle relazioni che intercorrono tra le componenti del sistema Sono proprietà che possono essere valutate e misurate solo in seguito all’integrazione delle componenti del sistema.. Esempi di proprietà di un sistema T Il peso complessivo del sistema T Può essere calcolato a partire dalle proprietà delle componenti del sistema T L’affidabilità del sistema T Dipende dall’affidabilità delle singole componenti e dalle relazioni che intercorrono tra le componenti T L’usabilità di un sistema T Non dipende solo dalle componenti hw o sw, ma anche dall’ambiente e dagli operatori.

(4) Fattori che influenzano l’affidabilità T Affidabilità dell’hardware T Qual è la probabilità che una componente hardware si rompi e quanto temo ci vuole a ripararla? T Affidabilità del software T Qual è la probabilità che il software produca un output non corretto? T Affidabilità degli operatori T Qual è la probabilità che un utilizzatore del sistema commetta un errore?. I sistemi e il loro ambiente T I sistemi non sono indipendenti, ma sono inseriti in T T T T. un ambiente, la cui conoscenza va inclusa nella specifica L’obiettivo di un sistema più essere di modificare il proprio ambiente (es. sistema di riscaldamento) L’ambiente può condizionare il comportamento del sistema (es. blackout) Un sistema può essere visto come un sottosistema del proprio ambiente Sull’ambiente si devono fare delle assunzioni.

(5) Sistemi e sottosistemi

(6)

(7).

(8).

(9). . . . Acquisizione di un sistema T Un sistema può essere costruito o acquisito. T Per acquisire un sistema per una azienda per T T. soddisfare una qualche necessità è necessario dare la specifica del sistema e l’architettura di progetto Scegliere tra sistemi o sottosistemi da comprare “off the shelf” e quelli da sviluppare in modo specifico su contratto. Fornitori e sotto-fornitori.

(10) Modello contraente/sottofornitori . . . . Acquisizione di un sistema

(11). . . . .

(12)

(13) . ,O SXQWR GL SDUWHQ]D q LQ HQWUDPEL L FDVL OD VSHFLILFD GHO VLVWHPD.

(14)

(15). .

(16)

(17). .

(18)

(19)

(20).

(21)

(22)

(23).

(24) Progettazione di un sistema T Coinvolge inevitabilmente tecnici di aree diverse, con T T T. problemi di “vocabolario” e metodologia Usualmente segue un modello di sviluppo a cascata, per poter sviluppare parallelamente le diverse componenti del sistema C’è poco spazio per iterazioni tra le varie fasi, per gli alti costi di modifica Il sottosistema “software” è quello più flessibile (fa da collante). Multidisciplinarietà .

(25) .

(26)

(27)

(28) .

(29)

(30) .

(31)

(32) .

(33)

(34) . .

(35)

(36)

(37)

(38)

(39)

(40).

(41) Architettura di riferimento. Il contesto....

(42) Sviluppo di un sistema

(43) . ! .

(44)

(45)

(46)

(47)

(48) .

(49)

(50).

(51) .

(52)

(53)

(54)

(55)

(56) .

(57)

(58) . 1RQ FL VRQR EDFNDUURZV. Definizione dei requisiti T Quali sono i requisiti globali del sistema? T Requisiti funzionali: cosa il sistema deve fare T Requisiti non funzionali: T proprietà del sistema, ad es. sicurezza, efficienza... T vincoli sul sistema, ad es. vincoli d’ambiente… T caratteristiche che il sistema non deve esibire.

(59) Esempio T Possibili requisiti per un sistema per la sicurezza di un edificio. T Costruire un sistema di allarme contro incendi e furti per T. l’edificio che segnali all’interno ed all’esterno la presenza di un incendio o di un’intrusione non autorizzata. Costruire un sistema che assicuri che il normale funzionamento del lavoro svolto nell’edificio non sia turbato da eventi come incendi o intrusioni non autorizzate.. Progettazione in sottosistemi T Organizzare i requisiti, separandoli T valutare le alternative possibili T Identificare i sottosistemi T Assegnare requisiti ai sottosistemi T Specificare la funzionalità dei sottosistemi T Definire le interfacce dei sottosistemi T È il punto critico per la parallelizzazione.

(60) Sviluppo dei sottosistemi T Tipicamente eseguito in parallelo T Problemi di comunicazione tra i vari team di. sviluppo T Può implicare l’acquisizione di sistemi “off the shelf”. Integrazione del sistema T E’ il processo di mettere assieme hardware,. software e risorse umane T Non è possibile un approccio “big-bang!” T Deve essere eseguito incrementalmente T i sottosistemi vanno integrati uno alla volta T questo riduce i costi di individuazione degli errori T E’ qui che emergono i problemi di interfaccia e di coordinamento tra le diverse componenti.

(61) Installazione T Le ipotesi sull’ambiente possono rivelarsi non T T T T. corrette Opposizione all’introduzione di un nuovo sistema da parte degli operatori Coesistenza per un certo periodo con sistemi preesistenti Problemi fisici di installazione (cablaggio...) Formazione degli operatori. Messa in opera T Mette in luce i requisiti non contemplati T Gli utenti possono usare il sistema in modo. difforme da quello anticipato dai progettisti T Può rivelare problemi nell’interazione con altri sistemi T Problemi nell’uso di interfacce diverse che possono indurre in errore gli operatori.

(62) Mantenimento e Smantellamento T I grossi sistemi hanno una lunga durata.. T T T T. Devono evolvere per soddisfare requisiti in evoluzione L’evoluzione è intrinsecamente costosa Obsolescenza dei sistemi Lo smantellamento del sistema può avere impatti sull’ambiente esterno Può richiedere la riconversione di dati per l’uso in altri sistemi. Modellare l’architettura di un sistema T Il modello architetturale di un sistema mostra. in modo astratto la struttura in sottosistemi T Dovrebbe rappresentare i flussi di informazione tra i vari sottosistemi T Usualmente è presentata in diagrammi a blocchi T Dal modello si dovrebbero identificare i diversi tipi delle componenti funzionali di un sistema.

(63) Esempio Radar system. Transponder system. Position processor. Aircraft simulation system. Data comms. system. Aircraft comms.. Telephone system. Comms. processor. Backup position processor. Backup comms. processor. Flight plan database. Weather map system Accounting system. Controller info. system. Controller consoles. Activity logging system. Esempio: un sistema di allarme .

(64) .

(65) . . . . . .

(66) Le componenti funzionali di un sistema T Sensori: derivano informazione dall’ambiente T Attuatori: determinano cambiamenti nell’ambiente T Componenti di calcolo: eseguono delle T T T. computazioni input -> output Componenti di comunicazione: permettono ad altre componenti del sistema di comunicare Componenti di coordinamento: coordinano le operazioni delle varie componenti Interfacce: trasformano rappresentazioni usate in una componente del sistema in un’altra rappresentazione. Esempio sensore. sensore .

(67) . coordinam.

(68) . attuatore . interfaccia . comunicaz. . centro di controllo esterno.

(69)