Accordo CINI-Finmeccanica: Iniziativa Software

Slides:



Advertisements
Presentazioni simili
Algoritmi e Strutture Dati
Advertisements

CORSO DI RECUPERO CONTROLLI AUTOMATICI Prof. Filippo D’Ippolito
2. Introduzione alla probabilità
PUNTATORI Introduzione
1 Modellare le infrastrutture critiche Giovedì 25 settembre 2008 Salvatore Tucci Presidente AIIC Ordinario di Calcolatori Elettronici Università di Roma.
6. Catene di Markov a tempo continuo (CMTC)
1 2. Introduzione alla probabilità Definizioni preliminari: Prova: è un esperimento il cui esito è aleatorio Spazio degli eventi elementari : è linsieme.
Inferenza Statistica Le componenti teoriche dell’Inferenza Statistica sono: la teoria dei campioni la teoria della probabilità la teoria della stima dei.
Lez. 3 - Gli Indici di VARIABILITA’
1 di di 16 CEPIS Il CEPIS, Council of European Professionals Informatics Societies, è la federazione delle associazioni informatiche europee Federa.
Realizzazione del file system
Economia Applicata all’Ingegneria
6. Catene di Markov a tempo continuo (CMTC)
3. Processi Stocastici Un processo stocastico è una funzione del tempo i cui valori x(t) ad ogni istante di tempo t sono v.a. Notazione: X : insieme di.
Implementazione dell algortimo di Viterbi attraverso la soluzione del problema di cammino mi- nimo tramite software specifico. Università degli studi di.
Metodi Quantitativi per Economia, Finanza e Management Lezione n° 11.
La valutazione degli investimenti
GESTIONE DELLA PRODUZIONE
1 14. Verifica e Validazione Come assicurarsi che il software corrisponda alle necessità dellutente? Introdurremo i concetti di verifica e validazione.
Semantiche dei linguaggi di programmazione
rendicontazione delle Aziende Sanitarie
Distributed Object Computing
Domenico Presenza Dimostratore MAIS per il dominio turistico Presentazione specifiche dei prototipi (R8.2.4) Milano – 17 Novembre 2004.
Identificazione delle attività
DIPARTIMENTO DI ELETTRONICA E INFORMAZIONE Puntatori Marco D. Santambrogio – Ver. aggiornata al 21 Marzo 2013.
Camil Demetrescu, Irene Finocchi, Giuseppe F. ItalianoAlgoritmi e strutture dati Algoritmi e Strutture Dati Capitolo 2 Modelli di calcolo e metodologie.
Camil Demetrescu, Irene Finocchi, Giuseppe F. ItalianoAlgoritmi e strutture dati Algoritmi e Strutture Dati Capitolo 2 Modelli di calcolo e metodologie.
7. Teoria delle Code Una coda è costituita da 3 componenti fondamentali: i serventi i clienti uno spazio in cui i clienti attendono di essere serviti.
1 Corso di Laurea in Biotecnologie Informatica (Programmazione) Introduzione a JAVA Anno Accademico 2009/2010.
1 Corso di Informatica (Programmazione) Lezione 10 (12 novembre 2008) Programmazione in Java: espressioni booleane e controllo del flusso (selezione)
1 Corso di Laurea in Biotecnologie Informatica (Programmazione) Problemi e algoritmi Anno Accademico 2009/2010.
Corso di Laurea in Biotecnologie Informatica (Programmazione)
Testing e Debugging.
Specifiche senza JML: uso delle asserzioni. 2 Asserzioni in Java Dal jdk 1.4 (da Febbraio 2002) cè meccanismo per gestire asserzioni Asserzione: espressione.
Physically-based Animations of 3D Biped Characters with Genetic Algorithms Università di Roma La Sapienza Relatore: Prof. Marco Schaerf Correlatore: Ing.
Area: la gestione dei progetti complessi
CONTROLLO DI SUPPLY CHAIN MEDIANTE TECNICHE H-INFINITO E NEGOZIAZIONE
Roberto Boggio Direttore Generale Call Center Services S.r.l.
Algoritmi e Strutture Dati
Algoritmi e Strutture Dati
Queuing or Waiting Line Models
Strutture di controllo in C -- Flow Chart --
Num / 36 Lezione 9 Numerosità del campione.
Le funzioni.
Intelligenza Artificiale
Il Problema della Compatibilità Anno 2000 Ministero del Tesoro del Bilancio e della Programmazione Economica CONSIP S.p.A.
Analisi di Immagini e Dati Biologici
Elementi di Informatica di base
Scheda Ente Ente Privato Ente Pubblico. 2ROL - Richieste On Line.
Il processo di sviluppo del Sw: strategia make
Radix-Sort(A,d) // A[i] = cd...c2c1
Metodi a gruppi per lidentificazione di modelli termici con selezione dei dati IDENTIFICAZIONE TERMODINAMICA DI UN EDIFICIO Alberton Riccardo, Ausserer.
21 marzo 2002 (ri-)Avvisi: Giovedi 28 marzo la lezione e sospesa. Nuovo indirizzo di Spedire messaggi e esercizi solo.
Andrea Capiluppi Dipartimento di Automatica e Informatica Politecnico di Torino, Italy & Computing Dept. The Open University, UK AICA 2004, Benevento,
Ingegneria del software Modulo 2 -Il software come prodotto Unità didattica 2 -I costi del software Ernesto Damiani Università degli Studi di Milano Lezione.
Sviluppare un programma in C che, dato un array da 100 elementi interi caricato con numeri casuali compresi tra [10,100], sia in grado di cercare il valore.
Distribuzione per causa delle irregolarità al servizio Azienda ATL (Valori assoluti) 1.
1 How to generate testing models into MDA approach to software development. A beginner’s point of view. Università degli Studi dell’Aquila Facoltà di Scienze.
Il linguaggio Fortran 90: 3. Procedure e Funzioni
Calcolo dei costi di riferimento e simulazione
redditività var. continua classi di redditività ( < 0 ; >= 0)
Fondamenti di Informatica 2 Ingegneria Informatica Docente: Giovanni Macchia a.a
1 Bernardo Mattarella 14 maggio 2003 Operational Risk Il Nuovo Accordo sul Capitale.
Ingegneria del software Modulo 2 -Il software come prodotto Unità didattica 2 - I costi del software Ernesto Damiani Università degli Studi di Milano Lezione.
Gestione del Traffico Aereo (ATM) ed Aeroporti Workshop ACARE Italia – Università Napoli - 14 Luglio 2006 Luigi IODICE.
Pianificazione ricavi SAP Best Practices. ©2013 SAP AG. All rights reserved.2 Finalità, vantaggi e passi fondamentali del processo Finalità  Pianificare.
Gestione trasferte SAP Best Practices. ©2013 SAP AG. All rights reserved.2 Finalità, vantaggi e passi fondamentali del processo Finalità  Fornire una.
Gestione dei numeri di serie SAP Best Practices. ©2013 SAP AG. All rights reserved.2 Finalità, vantaggi e passi fondamentali del processo Finalità  Descrizione.
Decision Tree Based Transient Stability Method A Case Study Gruppo 10: Alessandro Gambini Michele Leoni Sistemi informativi per le decisioni LS 15 marzo.
Standard e strumenti per lo sviluppo del software Marco Carezzano Andrea Andrenacci (ZEROPIU, Business Partner di Telecom Italia) Milano, 2 febbraio 2005.
Transcript della presentazione:

Accordo CINI-Finmeccanica: Iniziativa Software Progetto di ricerca “Testing dei sistemi software distribuiti mission-critical” Definizione e sperimentazione di tecniche avanzate di testing dei sistemi software distribuiti mission-critical Working group: Prof. S. RUSSO, Dott. M. LOFFREDA, PhD G. Paolillo, PhD R. Pietrantuono, Ing. G. CAMPANILE

Outline Descrizione linea di ricerca Approccio proposto per il testing Caso di studio: Swim Box Stato d’avanzamento Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Linea di ricerca - Descizione del problema Tematica Tecniche avanzate di testing per sistemi software distribuiti mission-critical Criterio generale: allocare più risorse per i componenti più critici, ma … Come quantificare la criticità dei componenti? Quante risorse sono necessarie? Quanto le interazione tra componenti influenzano la reliability totale del sistema? Come ottimizzare l’utilizzo delle risorse destinate al testing al fine di assicurare un prestabilito livello di reliability e minimizzare il costo totale del testing Obiettivo Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Approccio proposto (1/6) Obiettivo: assicurare un desiderato livello di reliability minimizzando i costi di testing attraverso la definizione di una allocazione ottima delle risorse di testing Identificazione dei componendi più critici Allocazione delle risorse di testing Tenendo in considerazione: Le relazioni tra le componenti dell’architettura L’eventuale presenza di meccanismi di Fault Tolerance La reliability del sistema operativo Inoltre: I componenti possono essere definiti a diversi livelli di granularità (subsystem, component, object, …) La soluzione stessa sarà definita a diversi livelli di dettaglio Ref. Software reliability and testing time allocation: an architecture-based approach , R. Pietrantuono, S. Russo, K. S. Trivedi, IEEE transactions on Software engineering, year: 2010, volume: 36 , issue: 3 Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Approccio proposto (2/6) Modellazione del sistema: catene di Markov a tempo discreto (Absorbing DTMC – Discrete Time Markov Chain) Gli stati rappresentano i componenti (Cj) Le transizioni il trasferimento del controllo tra i componenti Il sistema operativo OS è rappresentato con un apposito stato dal quale si transita attraverso le system call Il conteggio delle visite (visit count) per considerare l’utilizzo medio dei componenti C1 C3 OS P24 POS-1 P1-OS P12 P34 P23 P21 POS-3 P3-OS Sys Calls C4 C2 Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Approccio proposto (3/6) La reliability totale del sistema Rsys è calcolata considerando le reliability individuali dei componenti Ri ed i visit count VJ Pi,j= probabilità di transizione Vj = numero atteso di visite dove qj = probabilità che l’applicazione parta dal componente CJ m = numero di absorbing state La reliability attesa del sistema è: E[Rsys] = (∏in RiVi) * KVOS dove KVOS è la reliability dell’OS stimato come 1 - limn F/n, durante gli n test di una versione precedente (F è il numero di fallimenti) Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Approccio proposto (4/6) Si assume che la reliability di ogni componente cresca con il testing time La relazione è descritta dal modello SRGM (Software Reliability Growth Model) TestingTime = f(Reliability) Il modello minimizza il costo totale del testing garantendo che Rsys < Rmin : Minimize Tt = ∑i fi(λi) Subject to E[Rsys] = (Πin RiVi ) * KVos ≥ Rmin dove λ è la failure intensity Le tecniche di mitigazione dei fallimenti considerati sono: Riavvio del componente Riesecuzione da parte dell’applicazione Switch automatico in caso di fallimento (failover to a standby) Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Approccio proposto (5/6) Le tecniche di mitigazione dei fallimenti: La formula della reliability del sistema in presenza di un componente Ci dotato di mitigation means diviene: E[Rsys] = (Πin RCiVi ) * KVos dove RCi = 1 - Pr(componente Ci fallisca) Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Approccio proposto (6/6) Informazioni necessarie per applicare l’approccio Informazioni sull’architettura Identificazione dei componenti, probabilità di transizione (o conteggio di esecuzione) Informazioni sui componenti Tempo speso per visita, reliability dell’OS, metriche di complessità, tempi tra i fallimenti/tipi di guasti e copertura, parametri dei meccanismi Metodologie (non alternative) per estrarre tali info: Dal progetto: documenti (diagrammi UML), tool di analisi statica del codice e tool di simulazione Da profilazione dinamica: estraendo dei profili dall’esecuzione dei casi di test di una versione precedente Attraverso dati storici e/o con l’ausilio di esperti Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: SWIM-SUIT prototype L’approccio proposto sarà applicato alla verifica del prototipo realizzato da Selex-SI/SESM nel progetto europeo: SWIM-SUIT (System Wide Information Management SUpported by Innovative Technologies) 10 Countries, 20 Partners: 6 Industrie, 1 Airporto, 1 azienda di gestione, 2 compagnie aeree, 4 ANSPs, 4 SMEs, 2 Centri di ricerca, 1 Università RTD project (STREP) Call 4b of the 6FP Budget: 11,8 M€ 6,3 M€ finanziati dalla EC Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: SWIM-SUIT prototype OBIETTIVO: Verificare la bontà dell’approccio proposto su un sistema mission-critical Il testing del prototipo è stato già affrontato nell’ambito del progetto SWIM-SUIT utilizzando test funzionali allocati uniformemente tra i diversi componenti Attraverso l’allocazione delle risorse di testing, secondo l’approccio proposto, si vuole dimostrare un improvement della reliability del sistema a parità di risorse totali di testing utilizzate Consolidare attraverso l’esperienza sul campo una metodologia di testing, in particolar modo nella pianificazione dei test, da utilizzare per sistemi mission- critical Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: SWIM-SUIT prototype Il progetto SWIM-SUIT ha realizzato il prototipo SWIM-BOX: ATM Domain Components Core Components To/From DataLink Layer To/From ATM Stakeholders Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: Analisi del software (1/2) Individuazione dei componenti: 3 componenti di alto livello (ATM Domain Components): FDD, SDD, AID 4 componenti di basso livello (Core Components): Pub/Sub, ShareDS, Req/Rep, Registry Lo studio attuale si è concentrato su 3 componenti, 1 di livello ATM Domain e due di livello core : FDD: 14 servizi esposti Pub/Sub: 14 servizi esposti ShareDS: 3 servizi esposti Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: Analisi del software (1/2) Componente Flight Data Domain (FDD) CSCI FUNCTION IN 1 IN 2 IN 3 OUT FDD createFO FlightObjectCluster[]   FlightIdentifier updateFO Boolean readFO FlightObject readFOs FlightIdentifier[] FlightObject[] readFOSummary FlightSummary[] requestFOService FlightObjectRelease String[] ComplexReport handoverFO setFilteringCriteria FilteringCriteria unsetFilteringCriteria AvailableFilteringCriteria[] subscribe StakeholderIdentifier EndPoint unsubscribe void addMeAsParticipant FDDRole removeMeAsParticipant boolean getRoleForFlight Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: Analisi del software (1/2) Componente Publish/Subscribe (PSS) CSCI FUNCTION IN 1 IN 2 IN 3 OUT PSS activatePublisher SwimTopic[]   Boolean activateSubscriber Filter[] DataListener[] deactivatePublisher deactivateSubscriber getFilter SwimTopic Filter getMessages Int SWIMPublishedData[] isPublisherActivated isSubscriberActivated isSubscriberActivatedForPull isSubscriberActivatedForPush publish removeFilter setFilter Componente Share Data Store (SDS) CSCI FUNCTION IN 1 IN 2 OUT SDS getData Storekey   SharedData setData bolean removeData Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: Analisi del software (2/2) Metriche dimensionali del codice: Metriche/ Componenti FDD SDD AID Pub/Sub SharedDS REG Req/Rep CountLineComment 4.774 3.348 635 4.321 180 1.668 406 RatioCommentToCode 0,48 1,18 1,2 0,35 0,67 1,17 1,15 CountDeclFile 110 41 3 100 4 26 2 CountLineBlank 2.092 59 4.524 42 47 CountStmtDecl 3.142 1.000 163 3.478 73 495 132 CountDeclFunction 619 179 23 887 18 131 15 CountLine 16.636 3.473 638 21.032 491 1.796 408 CountStmtExe 4.089 991 213 5.595 126 380 116 CountLineCode 9.875 2.829 530 12.333 270 1.425 353 CountDeclClass 103 28 Legenda: FDD: Flight Data Domain SDD: Surveillance Data Domain AID: Aeronautical Information Service Domain Pub/Sub: Publish/Subscribe Service SharedDS: Shared Data Store REG : Registry Req/Rep: Request/Reply CountLineComment -- Number of lines containing comment. This can overlap with other code counting metrics. RatioCommentToCode -- Ratio of number of comment lines to number of code lines. CountDeclFile -- Number of files. CountLineBlank -- Number of blank lines. CountStmtDecl -- Number of declarative statements. Note that there can be overlap here with executable statements - int i = 0; CountDeclFunction -- Number of functions. CountLine -- Number of all lines. CountStmtExe -- Number of executable statements. Note that there can be overlap with declarative statements (int i = 0; ) CountLineCode -- The number of lines that contain source code. Note that a line can contain source and a comment and thus count towards multiple metrics. CountDeclClass -- Number of classes. Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: Analisi del software (2/3) Metriche di complessità ciclomatica del codice: FDD SDD AID Pub/Sub SDS REG Req/Rep AVARAGE COMPLEXITY Avg Cyclomatic 2,68 2,22 4,04 2,46 3,06 1,75 3,33 Max Cyclomatic 57 29 16 35 13 12 17 Max Nesting 9 5 4 3 6 SUM COMPLEXITY Count Path 8029123 92592 652 807148 78 292 1209 Sum Cyclomatic 1707 397 93 2195 55 229 50 Sum Essential 1092 226 70 1204 44 149 26 Legenda: FDD: Flight Data Domain SDD: Surveillance Data Domain AID: Aeronautical Information Service Domain Pub/Sub: Publish/Subscribe Service SharedDS: Shared Data Store REG : Registry Req/Rep: Request/Reply Avg Cyclomatic -- Average cyclomatic complexity for all nested functions or methods. Max Cyclomatic -- Maximum cyclomatic complexity of all nested functions or methods. Max Nesting -- Maximum nesting level of control constructs (if, while, for, switch, etc.) in the function. Count Path -- Number of unique paths though a body of code, not counting abnormal exits or gotos. Sum Cyclomatic -- Sum of cyclomatic complexity of all nested functions or methods. Sum Essential -- Sum of essential complexity of all nested functions or methods. Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: Analisi del software (2/4) Metriche di Halstead: Si basano su quattro indici ricavati dall’analisi del codice: n1: Numero di operatori univocamente presenti nel codice; n2: Numero di operandi (costanti e variabili) univocamente presenti nel codice; N1: Numero totale di occorrenze degli operatori nel codice; N2: Numero totale di occorrenze degli operandi nel codice.   A partire da questi si ricavano altri indici quali: Program Vocabulary (n): il vocabolario n del programma e definito come n = n1 + n2 Implementation Length (N): è una misura della dimensione del programma N=N1+N2 Program Volume (V): Rappresenta la dimensione dell’implementazione del programma e può essere pensata come il numero di bit richiesti per rappresentare l’intero programma nella sua forma minima (indipendentemente dalla lunghezza dei nomi dei token). Program Difficulty (D): Il livello di difficoltà o di propensione all’errore e proporzionale al numero degli operatori unici del programma: Effort to implement (E): Lo sforzo di programmazione può essere pensato come lo sforzo richiesto a comprendere l’implementazione piuttosto che a produrla: Number of delivered bugs (B): Il numero di Delivered Bugs è correlato con la complessità globale del software. Esso rappresenta una stima del numero di errori presenti nell’implementazione del sistema. Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: Analisi del software (2/4) Metriche di Halstead per i componenti ATM Domain:   FDD SDD AID Average Value Variance n1 2,0058026 50,827984 0,7812808 16,40574 0,1476846 4,6639647 n2 6,67795 1452,752 2,6216748 430,1582 0,60826033 100,798706 N1 36,03675 87718,24 9,832512 10615,328 2,255319 1550,0033 N2 24,734043 40876,25 7,1812806 5771,008 1,6633291 869,531 Vocabulary 8,683752 1920,9182 3,4029558 579,9657 0,7559449 148,00314 Length 60,770794 248219,83 17,013794 31998,137 3,9186482 4735,499 Volume 484,18375 2,022587E7 125,726105 2434715,8 29,98373 287974,8 Difficulty 2,7814314 154,77448 0,8699507 28,114206 0,18022528 8,956488 Effort 46501,395 3,87956146E11 6634,0195 1,7365164E10 1601,5745 9,5437338E8 Bugs Delivered 0,11014426 0,93304616 0,025274333 0,088539906 0,0066555715 0,01474004 Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Caso di studio: Analisi del software (2/4) Metriche di Halstead per i componenti core:   Pub/Sub SharedDS REG Req/Rep Average Value Variance n1 5,5627704 132,42424 0,88409704 21,849209 0,5854545 12,509381 0,07549505 2,520328 n2 16,91775 2232,1868 2,115903 187,9349 1,5781819 126,844154 0,38118812 87,432076 N1 99,52597 150450,4 11,838275 7925,369 5,9624243 2549,1096 1,4344059 1388,7773 N2 72,61256 80109,16 8,328841 4094,0745 4,3854547 1374,5791 1,095297 803,35876 Vocabulary 22,48052 3291,3857 3,0 324,33963 2,1636364 214,53555 0,45668316 118,22574 Length 172,13853 449723,75 20,167116 23361,201 10,347878 7654,6357 2,529703 4304,862 Volume 1293,8853 3,2003052E7 139,7089 1224271,1 69,37697 399238,3 20,336634 290819,97 Difficulty 9,809524 632,669 1,4150944 76,46329 0,7151515 25,113071 0,09777228 4,996591 Effort 134772,33 8,6436735E11 9449,698 7,152404E9 3070,0242 1,3668311E9 1180,1857 1,0768553E9 Bugs Delivered 0,35182166 2,3403342 0,038257774 0,092384934 0,016456466 0,024251778 0,0042476472 0,012598781 Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Attività in corso Le attività attualmente in corso prevedono: Individuazione delle probabilità di transizione a partire dallo studio del codice e con l’ausilio di esperti di dominio Definizione della catena di Markov tempo discreto che rappresenti il sistema Riduzione dei casi di test attraverso l’utilizzo delle classi di equivalenza Progettazione delle classi Tester per il testing funzionale sulla base delle classi di equivalenza precedentemente definite   Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

Grazie dell’attenzione   Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.