aicas news - aicas.com

aicas news l Sommer 2010
aicas
realtime
aicas news
News für Software-Entwickler kritischer Anwendungen Editorial
JamaicaVM 6.0 jetzt erhältlich
Liebe Leser,
JamaicaVM integriert OpenJDK
kürzere Innovationszyklen erhöhen den
Druck, qualitativ hochwertige Anwendungen in immer kürzerer Zeit zu produzieren. Die Kundenwünsche wachsen und der Wettbewerb wird härter.
Zur Steigerung der Produktivität sind
gute Werkzeuge daher unabdingbar.
Version 6.0 von JamaicaVM, der hart
echtzeitfähigen „Embedded Java“-Lösung von aicas, ist nun erhältlich. Die
neue Version unterstützt den Java 1.6
Standard, was durch den Versionssprung von 3.4 auf 6.0 verdeutlicht wird.
Wir bieten Ihnen Werkzeuge, mit denen
Sie diese Herausforderung bewältigen
können. Die jüngste Version der JamaicaVM ist nicht nur die bisher vollständigste „Embedded Java“-Plattform. Mit
Features wie Smart Linking und einem
effizienten Compiler ist sie optimiert,
um maximale Leistung bei minimalem
Speicherverbrauch und kürzester Startzeit zu erzielen. Unser neues Werkzeug
VeriFlux hilft Ihnen, Fehler in Ihrer Anwendung aufzuspüren ud somit die
Qualität Ihrer Produkte noch weiter zu
verbessern.
Neben der Vorstellung dieser neuen
und erweiterten Produkte werfen wir in
dieser Ausgabe einen Blick auf die Neuerungen in den Zertifizierungsstandards
der Luftfahrtindustrie und deren Auswirkungen auf die Software-Entwicklung. Ebenso wie gute Werkzeuge sind
gut durchdachte Klassenhierarchien entscheidend für die Zertifizierung.
Ich hoffe, Sie finden die Artikel in unserem Newsletter hilfreich und freue
mich auf Ihr Feedback.
Dr. James J. Hunt, CEO aicas
Sommer 2010
Das aicas-Team hat die Umstellung der
JamaicaVM von Classpath-basierenden
Standardklassen auf OpenJDK-Klassen nun vollendet. Ermöglicht wurde dies durch die Veröffentlichung von SUNs
Standardklassen unter der Classpath-Lizenz, welche die Verwendung auch in
kommerziellen Projekten gestattet. Alle
Änderungen, die das aicas-Team an dieser Code-Basis vorgenommen hat, wurden an die Community weitergegeben,
um sie in neue
OpenJDK-Versionen einfliessen zu
lassen.
Ergänzt
wurde
Ja-
maicaVM 6 um Optimierungen an der
eigenen RTSJ-Implementierung, Speicherverwaltung und statischen Kompilierung. Auch die Unterstützung für einige Betriebssysteme wurde deutlich
verbessert. Im Vergleich zur Vorgängerversion konnte JamaicaVM 6.0 seinen Wettbewerbsvorsprung hinsichtlich
Echtzeitfähigkeit und Portierbarkeit sogar noch ausbauen.
Markenzeichen von aicas‘ Echtzeit-Java-Technologie war stets die breite Verfügbarkeit auf einer großen Anzahl
verschiedener Betriebssysteme und Prozessorarchitekturen. JamaicaVM 6.0 ergänzt nun die bislang fehlende Grafikunterstützung unter Windows und
QNX Neutrino. Bei QNX können sowohl Photon als auch GF als mögliche
Grafikbibliotheken vom System angesteuert werden. VxWorks, WindowsCE, Linux, Solaris und OS9 werden selbstverständlich auch
weiterhin mit Grafik unterstützt.
Alle Grafikplattformen profitieren
von der erweiterten Implementierung von AWT, Swing und Java2D.
Darüber hinaus bietet JamaicaVM auch Unterstützung für verschiedene Versionen von OpenGL
zur 3D-Darstellung. Dies eröffnet neue
Möglichkeiten für Embedded-Grafik
mit Java, inklusive OpenGL ES sowie
OpenGL SC für kritische Systeme. Weitere Informationen zu OpenGL finden
Sie auf der Rückseite.
Eine voll funktionsfähige Evaluierungsversion von JamaicaVM 6.0 steht online
bereit unter:
http://www.aicas.com/download.html
News
Echtzeit-Java in der Luftfahrt
GL Studio für JamaicaVM
JamaicaVM für Multicore
Die neue “Object Oriented and Related
Technology”-Ergänzung zu DO-178C/ED12C wurde vom SC-205/WG-71 Plenum
verabschiedet. Dieses Dokument bereitet
den Weg für die Nutzung von EchtzeitJava-Technologie mit deterministischer
Speicherverwaltung. Durch konsistenter
Regeln zur Zertifizierung von Interpretern
und deterministischer Speicherverwaltung
wird die Nutzung von Java-Technologie in
sicherheitskritischen Systemen stark vereinfacht.
GL Studio 4 von DiSTI kann nun mit JamaicaVM 6.0 auf OpenGL-Plattformen genutzt werden. Das GUI erleichtert die Entwicklung von OpenGL-Anwendungen, die
aus grafischen Objekten zusammengesetzt
und wiederverwendet werden können.
Das Werkzeug ermöglicht Entwicklern die
schnelle und effiziente Erstellung von Anzeigen für echtzeit- und eingebettete JavaProgramme. Auf der Rückseite ist eine mit
GL Studio erstellte Anwendung zu sehen,
die von JamaicaVM ausgeführt wird.
JamaicaVM für Multicore- und Multiprozessorsysteme mit Intel x86-Prozessoren
wurde erfolgreich von ersten Pilotkunden getestet. Die Speicherverwaltung ist
vollständig parallelisiert, so dass einer
oder mehrere Prozessoren einen Teil der
Speicherbereinigung simultan durchführen können ohne andere Prozessoren zu
stören. Somit können optimale Leistung
und kurze Antwortzeiten erreicht werden.
Versionen für andere Prozessoren werden
im Laufe des Jahres verfügbar sein.
aicas news l Sommer 2010
Design einer sicheren Klassenhierarchie
Die Bedeutung der DO-178C für objekt-orientierte Techologie in Avionik-Software
Das „Joint Avionics“-Plenum ist dabei, die
neuen Zertifizierungsstandards für Avionik-Software fertigzustellen. Der neue
Standard soll Ende des Jahres verabschiedet werden. Dies wirkt sich nicht nur auf
die Richtlinien für „in-flight“- und Bodenbasierte Software aus, sondern auch auf
Software-Entwicklung für andere sicherheitskritische Anwendungsgebiete.
Während die derzeitigen Zertifizierungsstandards auf prozeduralen Paradigmen
beruhen, sind die neuen Standards allgemeiner. Die Änderungen erweitern die bestehenden Richtlinien für Software-Zertifizierung in der Luftfahrt und bieten
verschiedene Technologie-spezifische Ergänzungen. Dazu gehören WerkzeugQualifizierung, Modell-basierte Entwicklung, objektorienterte und verwandte
Technologien, sowie formale Methoden.
Für den Einsatz von Echtzeit-Java sind alle
diese Ergänzungen relevant. Am wichtigsten ist dabei die „Object Oriented and Related Technology (OOT)“-Ergänzung.
Die OOT-Ergänzung liefert das nötige Framework, um in Java geschriebene Avionik-Software zu zertifizieren. Sie enthält
klare Richtlinien für die Zertifizierung eines
Echtzeit-Garbage-Collectors, beispielsweise den work-based Garbage-Collector in
JamaicaVM. Andere Aspekte der Zertifizierung einer Java Virtual Machine (JVM), wie
z.B. Interpretation, werden ebenfalls abgedeckt. Diese Änderungen werden das
Risiko für den Einsatz von Echtzeit-JavaTechnologie in der Luftfahrt eliminieren.
Folgt ein JVM-Anbieter den Richtlinien des
Tools-Supplement, kann er die Kosten der
Zertifizerung über mehrere Projekte hinweg amortisieren, und reduziert dabei die
Kosten der einzelnen Projekte. Der Einsatz von Java-Technologie in sicherheitskritischen Projekten kann die Produktivität
als auch die Stabilität der Anwendungen
verbessern.
Um davon zu profitieren, ist ein Umdenken bei der Entwicklung von Avionik-Software erforderlich. Verglichen mit prozeduralen Sprachen ermöglicht OOT bessere
Kapselung und bedeutet gleichzeitig einen
dynamischeren Kontrollfluss. Dies ist das
zentrale Feature objekt-orientierten Designs und Programmierens und beeinflusst
die Entwicklung von Anwendungs-Code
am stärksten.
“Dynamic Dispatch” und Sicherheit
Die „Safety Critical Community“ hat bisher
objekt-orientierte Technologie mit Skepsis
betrachtet. Die Sorge galt vor allem der sicheren Nutzung von Vererbung, „Method
Override“ und dem in Java für Methoden
Aufrufe verwendeten „Dynamic Dispatch“.
SC-205/WG-71 Plenary
DO-178B/ED-12B
DO-248/ED-109
Mit diesen Features ist bei lokaler CodeBetrachtung nicht erkennbar, welche Methode tatsächlich an einem beliebigen
„Call Point“ ausgeführt wird. Oft wird aber
übersehen, dass „Dynamic Dispatch“ sicherstellt, dass der zur Bearbeitung jedes
Datentyps richtige Code ausgeführt wird.
Da Code direkt mit den Daten verbunden
ist, auf denen er arbeitet, wird es viel einfacher zu verstehen, was für diese Daten
gemacht werden muss. Es ist kein Zufall,
dass die am weitesten verbreitete Modellierungssprache Unified Modeling Language (UML), eine objekt-orientierte Sprache
ist. Richtig genutzt kann objekt-orientierte
Programmierung die verbesserte Modularität nutzen, um die Sicherheit und Robustheit von Programmen zu erhöhen.
Das liskovsche Substitutionsprinzip
Die Frage ist, was macht die vernünftige
Nutzung von Vererbung, „Method Overriding“ und „Dynamic Dispatch“ aus?
Wenn diese Frage nicht beantwortet werden könnte, dann müsste man jeden möglichen Dispatch an jedem „Call Point“ testen, analog zum Test verschachtelter
Anweisungen. Darauf zu bestehen würde
eine kombinatorische Explosion von Testfällen hervorrufen. Zum Glück gibt es eine
Antwort: Nutzen Sie das Typensystem um
sicheres Dispatching zu gewährleisten.
Viele objekt-orientierte Sprachen, wie Java,
C++ und Object Ada, besitzen statische Typisierung. Das Typsystem stellt sicher, dass
nur die deklarierte Klasse oder eine ihrer
Unterklassen zu jedem Zeitpunkt im Programm genutzt werden kann. Mit anderen Worten, wenn eine Variable oder ein
Feld als Klasse „A“ deklariert ist, dann können nur Instanzen von „A“ oder eine ihrer
Unterklassen dieser Variable oder diesem
Feld zugeordnet werden. Aus der Typisierungsperspektive ist eine Unterklasse einer Klasse ein Untertyp dieser Klasse. Dies reduziert die Zahl der beim Aufruf einer
überladenen Methode in Frage kommenden Implementierungen erheblich.
Damit ein Typ ein korrekter Untertyp
ist, muss er das gleiche Verhalten wie jeder seiner Obertypen zeigen. Mit anderen Worten, jeder Untertyp eines bestimmten Typen sollte an jeder Stelle nutzbar
sein, an der dieser Typ verwendet wird. Eine Unterklasse, die sich nicht an das Prinzip der Ersetzbarkeit hält, ist unzulässig, da
sie das Typsystem unsicher machen würde: Die Typenprüfung kann derartige Fehler nicht erkennen.
Dieses Prinzip, als liskovsches Substitutionsprinzip (LSP) bekannt, definiert formal,
was einen korrekten Untertypen auszeichnet. Liskov formulierte das Prinzip kurz
und bündig:
Sei q(x) eine beweisbare Eigenschaft von
Objekten x des Typs T. Dann soll auch q(y)
für Objekte y des Typs S wahr sein, wobei S
ein Untertyp von T ist.
Das LSP definiert die Grenzen des Verhaltens einer Unterklasse. Jede Methode, die in einer Unterklasse neu definiert wurde, muss die Anforderungen der
gleichen Methode in jeder ihrer Oberklassen erfüllen:
• Vorbedingungen können nicht gestärkt,
• Nachbedingungen nicht geschwächt
werden.
Zusätzlich dürfen Invarianten, die auf dem
Zustand einer Klasse definiert sind, nicht
geschwächt werden.
Das LSP ist der Schlüssel um sicherzustellen, dass Vererbung, „Method Overriding“
und „Dynamic Dispatch“ sicher genutzt
werden können. Solange sicher gestellt
ist, dass in einer Anwendung Unterklassen einer gegebenen Klasse stets auch korrekte Untertypen des Typs der Klasse sind,
kann man sich auf das Typsystem verlassen um zu argumentieren, dass die Nutzung von „Dynamic Dispatch“ in einem
Programm sicher ist.
Typsicherheit gewährleisten
Da Dispatching durch das Typsystem eingeschränkt wird, ist es dem Programmierer überlassen zu zeigen, dass alle Klassen dieser eingeschränkten Menge durch
ihre deklarierte Klasse ersetzbar sind. Das
bedeutet, dass für jeden Methoden-Aufruf jeder Teil der Menge möglicher Klassen, welcher ein Ziel für einen Dispatch
sein könnte, alle Anforderungen der deklarierten Klasse erfüllt.
Die einfachste Möglichkeit, Ersetzbarkeit
zu gewährleisten, ist zu zeigen, dass die
gesamte Klassenhierarchie eine korrekte
Typenhierarchie ist. Anders ausgedrückt
erfüllt jede einzelne Klasse die Anforderungen aller ihrer Oberklassen. Das kleine,
schmutzige Geheimnis objekt-orientierter
Sprachen ist, dass selbst Standardbibliotheken nicht vollständig korrekte Typenhierarchien sind.
Das bedeutet aber nicht, dass man keine
sicheren Programme schreiben kann. Das
wesentliche Problem ist, ob alle „dynamic
dispatches“ sicher sind oder nicht. Dies ist
primär ein lokales Problem.
Lokale contra globale Konsistenzen
Typenkonsistenz kann lokal oder global
betrachtet werden. Globale Typenkonsistenz ist Typenkonsistenz durch die gesamte Klassenhierarchie des Systems. Lokale Typenkonsistenz ist eine Untermenge
einer globalen Typenkonsistenz in einem
Kontext wo Ersetzbarkeit auftreten kann.
Ein lokaler Kontext kann der Kontext einer
Variablen, eines Attributs oder eines Para-
aicas news l Sommer 2010
meters sein. Es ist allgemein ausreichend,
lokale Typenkonsistenz für die Typensicherheit zu betrachten. Diese Eigenschaft
kann genutzt werden, um sicherzustellen,
dass nur anwendbare Methoden aufgerufen werden können.
Die OOT-Ergänzung benötigt nur lokale Typenersetzbarkeit. Dies bedeutet, dass
jede Klasse, die nicht in einem System als
deklarierte Klasse genutzt wird, oder eine Unterklasse davon ist, nicht für das
LSP betrachtet werden muss. Wenn neuer Code eingeführt wird, müssen die neuen Deklarationen natürlich in die LSP-Analyse aufgenommen werden. Allgemein gilt,
je niedriger eine Klasse in ihrer Klassenhierarchie ist, desto größer ist die Chance,
dass sie LSP-kompatibel mit ihrer Elternklasse sein muss.
Diese begrenzte Ersetzarbeit kann durch
formale Analyse oder Tests demonstriert
werden. Zu gewährleisten, dass alle Unterklassen einer Klasse alle Anforderungen
der Basisklasse erfüllen, bedeutet entweder, dass alle nötigen Tests der Basisklasse auch auf alle Unterklassen angewendet
werden müssen, oder die Bedingungen,
welche zum Beweis der Korrektheit der
Basisklasse genutzt wurden, auch für den
Beweis der Korrektheit aller Unterklassen
genutzt werden müssen. Somit wird das
Testen der Klassen von den Stellen entkoppelt, wo dispatching auftritt, und verhindert so die kombinatorische Explosion
von Tests und Verifizierungsfällen.
Druckerbeispiel
Ein Beispiel hilft dabei zu zeigen, wie
das LSP in der Praxis funktioniert. Nehmen Sie an, ein System hätte eine Klasse um Dokumente auszudrucken. Die Basisklasse könnte den Druck auf normalem
Papier implementieren. Wenn das Normalpapier Teil der Spezifikationen wäre,
könnte man keinen Untertyp spezifizieren, der auf Briefbögen druckt. Wenn andererseits der Papiertyp aber nicht Teil der
Spezifikation des Basistyps wäre, könnten
die Nutzer sich nicht auf die Eigenschaften
des Papiers verlassen. Wird ein Normalpapier-Drucker an irgend einer Stelle benötigt, dann muss eine Unterklasse dafür zur
Verfügung gestellt werden, selbst wenn sie
nichts anderes macht als die abstrakte Basisklasse.
Im Auge des Betrachters
Dieses einfache Beispiel macht einen
wichtigen Punkt deutlich. Wie eine Klasse spezifiziert ist, hat großen Einfluss darauf, wo eine Klasse als Implementierung
genutzt werden kann. Eine gute Klassenhierarchie aufzubauen ist nicht nur eine Frage der Implementierung, sondern auch der
Spezifikation. Die „Low Level“-Spezifikation eines Luftfahrtsystems muss das Design der Klassenhierarchie mit einschließen. Die Spezifikation einer Klasse sollte
ausreichen, um die korrekte Nutzung zu
gewährleisten, ohne vernünftiges „Subclassing“ zu unterbinden.
Die falsche Spur
Einige behaupten, es wäre unmöglich das
LSP auf Software-Entwicklung im normalen Arbeitsalltag anzuwenden. Ein Beispiel, dass genannt wird, ist die „ist gleich“Methode in Java. Nehmen wir an, man hat
eine „ist gleich“-Methode für eine Klasse
„Vector“ und eine Unterklasse „ColoredVector“. Wie soll dort ein „ist gleich“ funktionieren?
Generics bieten einen parametrischen Polymorphismus. Da Generics in Java mit
einem einzelnen Rumpf-Code implementiert sind, stellen sie nicht das gleiche Risiko wie Templates in C++ dar. Sie bieten
die Möglichkeit Code gemeinsam zu nutzen, der nicht den gleichen Typen wiederverwendet. Generics sind besonders hilfreich bei Objekten die eine Menge von
Dingen enthalten. Deshalb können eine
Liste von Wegpunkten und eine Liste von
Passagieren die gleiche Implementierung
teilen, haben aber charakteristische Typen.
Wenn die Elternklasse nur die Richtung
und Größe betrachtet, und die Un-
Die „Static Dispatch“-Falle
terklasse Richtung, Größe und Farbe,
dann wäre das Resultat eines „ist gleich“,
dass jeweils eine Instanz von „Vector“ und
„ColoredVector“ vergleicht, abhängig davon, auf welche Methode es angewandt
wurde, sprich die Reihenfolge der Operationen. Dies würde aber eine der fundamentalen Anforderungen von „ist gleich“
verletzen: Austauschbarkeit.
Nicht nur für sicherheitskritische
Anwendungen
Dieses Beispiel zeigt aber nicht, dass es
unmöglich ist das LSP anzuwenden, sondern nur, dass diese Implementierung,
und vielleicht die Spezifikation, inkorrekt
sind. Man hat unterschiedliche Möglichkeiten diese Sackgasse zu umgehen. Man
könnte voraussetzen, dass „ist gleich“ den
eigentlichen Typen ebenfalls betrachtet, so
dass Instanzen verschiedener Klassen niemals „gleich“ sind. Man könnte „ist gleich“
auf „Vector“ so definieren, dass keine zusätzlichen Zustände berücksichtigt werden. Schlussendlich könnte man sicherstellen, dass „Vector“ und „ColoredVector“
zwei Objekte als „gleich“ betrachten, in
dem sie eine „halbgleich“-Methode definieren und in beiden Permutationen testen. Es hängt davon ab, was angemessen
ist, wie man „ist gleich“ nutzt. Man kann
sogar verschiedene Arten von „ist gleich“
nutzen.
Delegation und Generics
Oft wird Vererbung genutzt um Code gemeinsam zu nutzen, aber es gibt sicherere
Wege dies zu tun. Eine Technik, die in den
meisten objekt-orientieren Sprachen dafür
genutzt werden kann, ist „Delegation“. Eine Methode kann eine Methode eines Objekts in einem privaten Feld aufrufen, um
die nötige Arbeit zu erledigen. Java bietet
dafür einen weiteren Mechanismus: Generics.
Das ist alles schön und gut, aber wäre ein „static dispatch“ nicht besser?
Dies ist ein weitverbreiterter Irrtum.
Zwar ist bei „static dispatch“ eindeutig, welcher Code bei einem Aufruf
zur Ausführung kommt. Dafür
ist es jedoch deutlich schwieriger sicherzustellen, dass
die Methode mit den Daten,
auf denen sie operiert, sinnvoll umgehen kann. Ist eine
Methode statisch dispatched
und wird überschrieben, ist es
schwer, das korrekte Verhalten zu gewährleisten.
Eine vernünftige Klassenhierarchie zu entwerfen ist nicht nur für sicherheitskritische
Projekte wichtig. Jedes objekt-orientierte
Programm kann von ordentlichem „Subtyping“ profitieren, das dabei hilft, dass
ein sich ständig weiter entwickelndes System korrekt funktioniert, auch wenn neue
Klassen hinzugefügt werden. Das Ergebnis sind bessere Test-Strategien und robustere Systeme.
Schlussfolgerung
Das Erscheinen des neuen Avionik-Standards wird das Risiko eliminieren, objektorientierte Technologien in der Luftfahrt
zu verwenden. Insbesondere der Einsatz
von Java-Technologie wird erheblich erleichtert. Durch die Bereitstellung klarer Richtlinien für die Entwicklung von
Java-Runtime-Systemen mit Speicherbereinigung (Garbage Collection), kann ein
Großteil der Last der dynamischen Speicherverwaltung vom Anbieter der JavaEntwicklungswerkzeuge übernommen
werden. Trotzdem muss der Anwendungsprogrammierer den Entwurf der Klassenhierarchien während der Ausarbeitung
der Anforderungen im Auge behalten, sowie einen korrekten Entwurf der Hierarchie und der Implementierung sicherstellen. Effektives und effizientes Testen, als
auch Verifizierungsstrategien hängen von
gutem System-Design ab. Obwohl dieses
Konzept nicht wirklich neu ist, bieten die
OOT-Ergänzungen bessere Richtlinien für
Entwickler und Sicherheitsgutachter.
aicas news l Sommer 2010
OpenGL
JamaicaVM unterstützt den Industriestandard für 3D-Grafik
Die standardisierte OpenGL API ermöglicht die Erstellung komplexer 3D-Szenen
unabhängig von der Plattform, und ist auch
für 2D-Rendering verwendbar. JamaicaVM
ermöglicht nun den Einsatz von OpenGL
auch in Echtzeit-Java-Anwendungen.
OpenGL ist in drei Varianten erhältlich: Neben dem vollwertigen OpenGL, wie es
vor allem in PCs zum Einsatz kommt, definiert der Standard außerdem die Untermengen OpenGL-ES und OpenGL-SC.
OpenGL-ES wurde entwickelt, um die Bedürfnisse von Embedded Systems, zum
Beispiel geringere Belastung der GrafikHardware, zu erfüllen ohne die Leistung
von OpenGL zu beeinträchtigen. OpenGLES wird oft in mobilen Geräten, wie z.B.
Navigationsgeräten, genutzt. OpenGL-SC
richtet sich an die Anforderungen von sicherheitskritischen Anwendungen, zum
Beispiel Grafik in Avionik-Systemen. Es basiert auf OpenGL-ES. Implementierungen
von OpenGL-SC, die auf DO-178B Level A
zertifiziert wurden, sind bereits kommerziell erhältlich.
Die neueste JamaicaVM bietet Java Bindings für alle drei Varianten von OpenGL,
und ermöglicht Kunden so den direkten
Zugriff auf OpenGL aus ihren Echtzeit-Java-Applikationen, die mit der JamaicaVMTool-Chain gebaut wurden. Sie können
zwischen Bindings für die Spezifikationen
JSR 231 und JSR 239 aus dem Java Community Process wählen. JSR 231, auch als
JOGL bekannt, bietet die Integration der
AWT und Swing Widget Sets. aicas bietet
JSR 231-kompatible JOGL Bindings sowohl
zum Zugriff auf vollwertiges OpenGL als
auch auf OpenGL ES an. JSR 239 ermöglicht direkten Zugriff auf OpenGL mittels
EGL. Dies ist eine schlanke Grafikschnittstelle, die durch OpenGL definiert ist, und
eingesetzt werden kann, wenn eine Fenster-Verwaltung wie X11 nicht verfügbar
oder nicht gewünscht ist. JSR 239 ist be-
Events
Wir würden uns freuen Sie auf den
folgenden Veranstaltungen begrüßen zu dürfen.
Java Forum Stuttgart
Stuttgart, 1. Juli 2010
JTRES
Prag, 19.-21. August 2010
ESC Boston 2010
Boston, MA, USA, 20.-23. Sept. 2010
SPS/IPC/Drives
Nürnberg, 23.-25. November 2010
sonders gut für mobile Geräte und
zur Zertifizierung geeignet. JamaicaVM bietet Bindings nach JSR 239
für OpenGL-ES und OpenGL-SC.
Alle 3 OpenGL-Varianten sind für
die JamaicaVM 6.0 Tool Chain verfügbar. Wenden Sie Sich einfach
an unser Vertriebsteam, das Ihnen
gerne dabei helfen wird, die passende OpenGL-Konfiguration für
Ihre Bedürfnisse zu finden.
VeriFlux
GL Studio OpenGL Anwendung mit JamaicaVM
Verbesserung der Code-Qualität durch formale Analyse
Eine zuverlässige Anwendung zu bauen
ist nicht nur Frage einer guten Entwicklungsumgebung, sondern auch von guten Verifizierungs-Werkzeugen. Glücklicherweise sind Java-Programme an sich
einfacher zu analysieren als Programme
in älteren Sprachen wie C und C++: Syntax und Semantik von Java-Programmen
sind strenger und damit weniger fehleranfällig. Gleichzeitig ist der Abstraktionsgrad höher. Das aicas-Team hat sich
seine Compiler-Technologie zu Nutze gemacht und VeriFlux, ein hochmodernes
Analyse-Werkzeug für Java-Programme,
entwickelt.
VeriFlux hilft sicherzustellen, dass verschiedene Fehlertypen vollständig aus ihren Java-Programmen eliminiert werden.
Das Werkzeug betrachtet alle möglichen
Ausführungspfade einer Anwendung,
um darin Fehler aufzuspüren,
die durch nicht-lokale Effekte
schwer erkennbar sind. Sowohl Laufzeitfehler wie
• ArithmeticException,
• ArrayStoreException,
• ClassCastException,
• IndexOutOfBoundsException,
• NegativeArraySizeException,
• NullPointerException und
• IllegalAssignmentError,
als auch Threading-Probleme wie Deadlocks und Race Conditions werden gefunden.
Anders als die meisten statischen Analyse-Werkzeuge ist VeriFlux sicher. Mit anderen Worten bedeutet dies, wenn für
einen bekannten Fehlertyp kein Fehler
gefunden wird, dann gibt es auch keinen
Fehler dieses Typs im analysierten Programm. Fehler, die durch normale Tests
nur schwer auffindbar sind, können so
durch VeriFlux vollständig eliminiert werden.
VeriFlux arbeitet auf Java Bytecode. Jedes
Programm, das kompiliert, kann auch
analysiert werden. Die Analyse beginnt
an einem festgelegten Eintrittspunkt. Mittels Datenflussanalyse und abstrakter Interpretation wird für jedes Vorkommen
einer Variablen im gesamten Aufrufbaum
die mögliche Wertemenge bestimmt. Die
abstrakte Interpretation minimiert dabei
unbegründete Warnungen.
VeriFlux unterstützt Reflektion und kann
viele einfache Fälle von Reflektion vollständig automatisch lösen. Komplexere
Fälle können mit minimaler Entwickler-Unterstützung analysiert werden. Mit
dem gleichen Mechanismus kann auch
nativer Code behandelt werden.
Das Werkzeug ermöglicht partielle ebenso wie vollständige Programm-Analyse.
Entwickler können VeriFlux dadurch bereits früh im Entwickungsprozess einsetzen, ebenso wie während der Systemintegration. Kontinuierliche
Nutzung von VeriFlux kann durch
frühzeitige Fehlererkennung die Entwicklungskosten senken. Das Resultat sind
weniger Fehler und robusterer Code.
Contact
aicas GmbH
Haid-und-Neu-Straße18
76131 Karlsruhe, Germany
+49 721 663 968-0
aicas incorporated
6 Landmark Square, Suite 400
Stamford, CT 06901, USA
+1 203-676-9807
aicas SARL
9 Allée de l’Arche
92671 Paris La Defense. France
+33 1 49 97 17 62
email
web
[email protected]
www.aicas.com