2009-10-14 Vorstellung Klocwork

Teilnehmer

TRUMPF: Maike Rehusch, Thilo Schönfelder, Georg Hochholzer EMENDA: Herr Halder FZI: Henning Groenda, Jens Happe

Agenda

Kontrollfluss
- Flow Chart generation aus AST
- return value / dead code detection
Data Flow
Struktur / Architektur
- Entities (siehe online Hilfe 'Supported Entity Types'; Bsp: DIRECTORY, FILE, ARCHITECTURE_BLOCK(virtuell)), Relationships
- Prüfung auf Ebene von Verzeichnissen ist machbar
- Bei weiteren Wünschen eher andere Programme (Bsp: Lattix)
- Keinerlei Modifikation bei what-if. Lediglich 'Todo-Liste'.
Metriken
- eindimensional
- lassen sich beliebig mit mathematischen Funktionen verketten
Export
- XML, HTML, XML --XSLT--> PDF
Unterstützte Sprachen
- C
- C++
- Java
- C# (nur IDE/client, Details WIRD ABGEKLÄRT)

Technische Basis
- AST, genannt KAST. Werkzeug darauf heißt Checker
- Path Checker. Wohl eher symbolische Ausführung (Wertebereiche, erweiterte Funktionen für Semaphoren, Ressourcen). DSL.
Benutzer-/Rollenverwaltung
- Ist integriert. Anbindung an existierende Lösungen (LDAP, NIS) machbar
- User, Gruppen, Rollen beliebig konfigurierbar
- Zuordnung von Usern auf Codebereiche: nur 1-1 (Textdatei mit Format (Zeile:) user;Datei)
Overhead
- Analyse ('Compile') ist um einen Faktor langsamer als 'normale' compilierung
- Hängt von Anzahl Checker ab
- Path-Analysen wohl nochmals aufwändiger
Knowledge-Base
- Einschränkung von Wertebereichen, Definition von Verhalten von nicht analysierten Funktionen
- Feedback bei fehlerhaftem Eintrag (WIRD ABGEKLÄRT)
Verwendete Server
- Flex für Lizenzverwaltung
- MySQL als Backend-Datenbank
- Klocwork Project Server
- Tomcat Webserver für grafische Darstellung/Reports

Ausschluss von Elementen
- Verzeichnissen/Dateien: Nicht analysieren
- Fehlern: (Analysieren) Filtern. Filter nach Verzeichnis, Datei, Issue Typ, User, State, Status.
- Konkreten checks nicht pro Datei einstellbar. Muss in eigenes 'Project' ausgelagert werden.

Aufgedeckte Fehler
- Zyklische Abhängigkeiten nur manuell in Architekturansicht
- Checker können mit Hilfe/Details verknüpft werden. VORSCHLAG: Bei Umsetzung der TRUMPF Guidelines sollte geometric dies mit machen. Web-Zugriff oder HTML-Format für diesen Guideline-Teil wäre also von Vorteil.
- Severity nicht frei konfigurierbar. Es gibt ~8 vordefinierte Kategorien, die verwendet werden müssen.

Workflow
- Verwaltbarer Zustand 'State'. Workflow muss definiert werden, welche Rolle welche Änderung wie machen darf.
- 'status' ist eine feste Einteilung auf serverseite der Bugs (analysiert, wiederaufgetreten, ...)

Reporting
- Für jede Ansicht muss ein eigenen Report generiert werden. VORSCHLAG: Grobentwurf FZI in Verbindung mit TRUMPF, Umsetzung geometric.

Email mit Exception-Beispiel wg Mächtigkeit der 'Checker': Lässt sich Einhaltung der Sicherheitsfassade prüfen? Kann die deklaration von Exceptions überprüft werden?
'checker exchange' anschauen
Evaluation des 'Speed-Factor' von Klocwork. Vergleich 'normale' compilierung und Klockwork 'compilierung'. Zusätzlich grobe Abschätzung für checker interessant.
Check Roadmap (WIRD ABGEKLÄRT)
Check price list (WIRD ABGEKLÄRT)
Metriken auf Architekturelementen statt auf File-basierter Ansicht (WIRD ABGEKLÄRT)
Guidelines: Festlegen, wie builds, ... heißen sollen, damit später Auswertungen auf Untermengen davon gefahren werden können (Reporting bspw: Alle Milestones plus letztes build)