Um Entwickler in ihrer täglichen Arbeit zu unterstützen, integrieren integrierte Entwicklungsumgebungen (IDEs) zunehmend mehr Hilfsmittel, die es Entwicklern erlauben, sich auf die inhärente Komplexität der Entwicklung zunehmend größerer Software Systeme zu konzentrieren. Die Komplexität der Entwicklung dieser Systeme wird unterteilt in inhärente Komplexität die aus der Komplexität der Problemstellung stammt, sowie accidentielle Komplexität die von der Unzulänglichkeit der verwendeten Werkzeuge und Methoden kommt und daher durch bessere Werkzeuge beseitigt werden kann. So bieten IDEs automatische Vervollständigung an, damit Entwickler sich nicht die genaue Schreibweise von Methoden merken müssen. Um Entwickler auf (potentielle) Fehler im Gebrauch der Programmiersprache hinzuweisen, werden Fehlermeldungen in der IDE mit dem Quelltext verknüpft. Um die Navigation in Projekten zu erleichtern bieten IDEs strukturelle Ansichten des Programms, wie z. B. die Typhierarchie an. IDEs ermöglichen Entwicklern, produktiver zu sein und Fehler früher zu finden, in dem sie kodifiziertes Expertenwissen nutzen. In IDEs werden statische Analysen benutzt, um Informationen aus dem Programm in Entwicklung zu extrahieren. Statische Analysen entdecken Eigenschaften von Programmen, ohne diese auszuführen. In der Vergan-genheit waren statische Analysen meist in Compilern integriert, um Fehler zu finden und kleineren oder schnelleren Code zu produzieren. Werden statische Analysen in IDEs integriert, öffnen sich ihnen neue Anwendungsgebiete. Unter diesen sind domainspezifische Analysen, optionale Typsysteme und das Überprüfen struktureller Eigenschaften. Optionale Typsysteme sind Typsysteme die die Laufzeitsemantik nicht verändern. Das erlaubt es, mehrere Typsysteme (zum Beispiel confined types und das Java Typ- system) zu kombinieren und von statischen Analysen prüfen zu lassen. Wenn diese Analysen Entwicklern zur Verfügung stehen, kann ein breiterer Bereich von Softwaredefekten erkannt werden. Durch das Integrieren der Analysen in die Entwicklungsumgebung kann dem Entwickler schneller und besser Rückmeldung gegeben werden. Das erlaubt es den Entwicklern, die Analysen in ihren alltäglichen Arbeitsablauf zu integrieren, da die Unmittelbarkeit der Rückmeldungen gewahrt bleibt. Um den vollen Vorteil der IDE Integration zu erreichen, müssen die Analysen zum Einen in den inkrementellen Übersetzungsvorgang eingebettet werden und zum Anderen müssen die Analysen die ausgeführt werden an das untersuchte Programm anpassbar sein. Ein Beispiel für einen offenen, modularen Ansatz um dies zu erreichen ist Magellan. Magellan ist eine offene statische Analyseplattform die in den inkrementellen Übersetzungsvorgang integriert ist und die es ermöglicht, statische Analysen in IDEs und insbesondere in den inkrementellen Übersetzungsvorgang zu integrieren. In dieser Arbeit werden Ansätze zur Inkrementalisierung statischer Analysen für integrierte, offene statische Analyseplattformen untersucht. Eine statische Analyse zu inkrementalisieren bedeutet, dass die Analyse die Ergebnisse eines vorhergenden Übersetzunsvorgangs und die Änderungen am Programm nutzt, um das Analyseergebnis an den aktuellen Zustand des Pro- gramms anzugleichen. Das Analyseergebnis ist dann äquivalent zu einer kompletten Analyse des Programms im aktuellen Zustand. Die Ansätze hierzu können in manuelle und automatische Inkrementalisierung eingeteilt werden. Manuelle Inkrementalisierung nutzt eine universelle Programmiersprache, wie beispielsweise Java, um eine statische Analyse zu implementieren, die die Inkrementalisierung in einem spezialisierten Algorithmus verwirklicht. Bei automatischer Inkrementalisierung wird die Analyse geschrieben, wie für die komplette Analyse, da Die zugrundeliegende Sprache beziehungsweise Framework einen Mechanismus anbietet, um die Analyseergebnisse an die Programmänderungen anzupassen. Gegenwärtig werden inkrementelle Analysen ad hoc entwickelt, mittels dem Ansatz, der dem Entwickler am vertrautesten ist. Wenn aber der Ansatz nicht der am besten geeignetste für das Problem ist, wird die Entwicklungs- zeit oder die Laufzeit der Analyse länger sein als notwendig. Um die Eigen- schaften von Analysen zu untersuchen, die die Wahl des Ansatzes beein- flussen, wurden drei Analysen ausgewählt. Diese Analysen wurden je einmal mit dem manuellen und dem automatischen Ansatz implementiert. Die ausgewählten Analysen repräsentieren Analysen, die den Daten- und den Kontrollfluss untersuchen, sowie Analysen die strukturelle Eigenschaften überprüfen. Die Analyse die Dateflusseigenschaften überprüft, sucht Verletzungen des optionalen Typsystems confined types. Die Analyse die den Kontrollfluss untersucht, erstellt und wartet einen intraprozeduralen call graph mit Hilfe der rapid type analysis (schnelle Typanalyse, RTA). Die Analyse die strukturelle Eigenschaften prüft, sucht nach Verletzungen von strukturellen Abhängigkeiten zwischen Belangen (concerns) im Programm. Die Ergebnisse deuten darauf hin, dass Analysen, die Abfragemechanismen (query engines) beinhalten, zumindest für diesen Teil automatische Inkrementalisierung nutzen sollten. Analysen, die sich nur in einfacher, Vorhersagbarer Weise konfigurieren lassen, eignen sich eher für manuelle Inkrementalisierung. Dann kann Wissen über das Fachgebiet der Problem- stellung Optimierungen ermöglichen, die sich nicht ohne weiteres in Umgebungen für automatische Inkrementalisierung integrieren lassen.