Accordo CINI-Finmeccanica: Iniziativa Software

Presentazione sul tema: "Accordo CINI-Finmeccanica: Iniziativa Software"— Transcript della presentazione:

1 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20 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, 132,42424 0, 21,849209 0, 12,509381 0, 2,520328 n2 16,91775 2232,1868 2,115903 187,9349 1, 126,844154 0, 87,432076 N1 99,52597 150450,4 11,838275 7925,369 5, 2549,1096 1, 1388,7773 N2 72,61256 80109,16 8,328841 4094,0745 4, 1374,5791 1,095297 803,35876 Vocabulary 22,48052 3291,3857 3,0 324,33963 2, 214,53555 0, 118,22574 Length 172,13853 449723,75 20,167116 23361,201 10,347878 7654,6357 2,529703 4304,862 Volume 1293,8853 3, E7 139,7089 ,1 69,37697 399238,3 20,336634 290819,97 Difficulty 9,809524 632,669 1, 76,46329 0, 25,113071 0, 4,996591 Effort 134772,33 8, E11 9449,698 7,152404E9 3070,0242 1, E9 1180,1857 1, E9 Bugs Delivered 0, 2, 0, 0, 0, 0, 0, 0, Testing Sistemi Sw Distribuiti Mission Critical Workshop Iniziativa Software II ed.

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

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