Strumento per il controllo di progetti C++ grandi e distribuiti come KDE?

Question

Esiste uno strumento in grado di gestire il controllo di modelli di sistemi distribuiti di grandi dimensioni, nel mondo reale, per lo più in C++, come KDE?

(KDE è un sistema distribuito nel senso che utilizza IPC, sebbene in genere tutti i processi si trovino sulla stessa macchina. Sì, a proposito, questo è un utilizzo valido di "sistema distribuito": verifica su Wikipedia.)

Lo strumento avrebbe bisogno di essere in grado di far fronte ad eventi intraprocess e messaggi tra processi.

(Supponiamo che se lo strumento supporta C++, ma non supporta le altre cose che KDE utilizza come moc, siamo in grado di incidere qualcosa insieme per aggirare questo.)

sarò felice di accettare meno generale (ad esempio, analizzatori statici specializzati per la ricerca di classi specifiche di bug) o alternative di analisi statiche più generali, al posto di veri e propri correttori di modelli. Ma mi interessano solo gli strumenti che possono in realtà gestire i progetti con le dimensioni e la complessità di KDE.

Answer 1

Stai ovviamente alla ricerca di uno strumento di analisi statica che può

• parse C++ su scala
• individuare frammenti di codice di interesse
• estrarre un modello
• pass che il modello a un modello checker
• rapporto che risultano a voi

Un problema significativo è che tutti hanno un'idea diversa sul modello che desiderano controllare. Che da solo probabilmente uccide le possibilità di trovare esattamente quello che vuoi, perché ogni strumento di estrazione modello ha generalmente fatto una scelta su ciò che si vuole catturare come modello, e le possibilità che corrisponda ciò che si vuole con precisione sono IMHO vicino a zero.

Non sei chiaro su cosa specificamente vuoi modellare, ma presumo che tu voglia trovare le primitive di comunicazione e modellare le interazioni di processo per verificare qualcosa come deadlock?

I venditori strumento di analisi statica commerciali sembra un posto più logico dove cercare, ma non credo che ci sono, ancora. Coverity sembrerebbe la soluzione migliore, ma sembra che abbiano solo una sorta di analisi dinamica per problemi di threading Java.

Questo documento sostiene di fare questo, ma non ho guardato in ogni particolare: Compositional analysis of C/C++ programs with VeriSoft. Related è [PDF] Computer-Assisted Assume/Guarantee Reasoning with VeriSoft. Sembra che tu debba annotare manualmente il codice sorgente per indicare gli elementi di modellazione di interesse. Lo strumento Verifysoft stesso sembra essere proprietario di Bell Labs ed è probabilmente difficile da ottenere.

Allo stesso modo questo: Distributed Verification of Multi-threaded C++ Programs.

Questo documento fa anche affermazioni interessanti, ma non elabora C++ nonostante il titolo: Runtime Model Checking of Multithreaded C/C++ Programs.

Mentre tutte le parti di questo sono difficili, un problema che tutti condividiamo è l'analisi C++ (come esemplificato dal la carta precedentemente citato) e trovare i modelli di codice che forniscono le informazioni prima per il modello. È inoltre necessario analizzare il dialetto specifico del C++ che si sta utilizzando; non è bello che i compilatori C++ accettano tutti lingue diverse. E, come è stato osservato, è necessario elaborare codici C++ di grandi dimensioni. I correttori di modello (SPIN e amici) sono relativamente facili da trovare.

Il nostro DMS Software Reengineering Toolkit fornisce l'analisi generale, con la corrispondenza di motivi personalizzabile e l'estrazione dei fatti, e ha un robusto C++ Front End che gestisce molti dialetti di C++. Potrebbe essere configurato per trovare ed estrarre i fatti che corrispondono al modello che ti interessa. Ma non lo fa da zero.

DMS con il suo C front-end sono stati utilizzati per elaborare applicazioni C estremamente grandi (19.000 unità di compilazione!). Il front-end C++ è stato utilizzato in rabbia su una varietà di progetti C++ su larga scala, ma non in generale a quella scala. Data la capacità generale del DMS, penso che sia probabilmente in grado di gestire blocchi di codice abbastanza grandi. YMMV.

Answer 2

Gli analizzatori di codici statici quando vengono utilizzati per la prima volta su base di codice grande di solito producono così tanti avvisi e allarmi che non sarà possibile analizzarli tutti in un ragionevole lasso di tempo. È difficile individuare problemi reali dal codice che sembra solo sospetto per uno strumento.

È possibile provare a utilizzare strumenti di rilevamento invarianti automatici come "Daikon" che catturano gli invarianti percepiti in fase di esecuzione. È possibile convalidare in un secondo momento se gli invarianti scoperti (equivalenza di variabili "a == b + 1" per esempio) hanno senso e quindi inserire affermazioni permanenti nel codice. In questo modo, quando l'invariante viene violato come risultato del tuo cambiamento, riceverai un avvertimento che forse hai rotto qualcosa con il tuo cambiamento. Questo metodo aiuta a evitare la ristrutturazione o la modifica del codice per aggiungere test e mock.

Answer 3

Il modo usuale di applicare tecniche formali a sistemi di grandi dimensioni è modulare e scrivere specifiche per le interfacce di ciascun modulo. Quindi è possibile verificare ogni modulo in modo indipendente (durante la verifica di un modulo, si importano le specifiche - ma non il codice - degli altri moduli che chiama). Questo approccio rende la verifica scalabile.