Optimieren durch Selektion –
Die Evolution im Algorithmus Teil 1

Bei der Lösung von Problemen lässt sich die Informatik häufig von anderen Wissenschaften inspirieren. Man denke nur an Neu­ronale Netze und die Möglichkeiten, die sich mit diesen eröff­nen. Doch während diese aufwendig angelernt werden müssen, bietet Darwin mit seiner Evolutionstheorie eine interessante und leicht umsetzbare Lösung für eine Vielzahl von Optimie­rungsproblemen. Wie man sich das Ganze vorstellen kann, soll diese Kolumne näher beleuchten.

Jeder ist sicher schon einmal auf Optimierungsprobleme gestoßen und hat überlegt, wie man diese algorithmisch lösen könnte. Ein Beispiel hierfür ist Ressourcenplanung. Dabei sollen Tasks in zeitlicher Begrenzung eine Menge von Ressourcen zugewiesen werden, um diese unter Beachtung verschiedener Gesichtspunkte, beispielsweise den entstehenden Kosten oder der benötigten Zeit, abzuarbeiten. Dies ist ganz klar ein Optimierungsproblem. Doch sind ausgefeilte, hochgradig spezialisierte Algorithmen oder Brute-Force die einzige Möglichkeit zur Lösung solch komplexer Optimierungsprobleme?

Dieser Artikel ist im Magazin JavaSPEKTRUM Ausgabe 01/2018 erschienen. Lesen Sie den vollständigen Artikel im Magazin oder hier:
Download Optimieren durch Selektion – Die Evolution im Algorithmus Teil 1 (PDF, 1 MB)

Der Artikel stellt den ersten von zwei Teilen zum Thema „Die Evolution im Algorithmus“ dar. Der zweite Teil wird sich mit multikriterieller Optimierung und automatisierter Architekturerkennung durch genetische Algorithmen beschäftigen. Er erscheint voraussichtlich im Magazin JavaSPEKTRUM Ausgabe 02/2018 (Erscheinungstermin: 23. März 2018).

Vielen Dank an JavaSPEKTRUM für die Bereitstellung des Artikels als PDF.

Sanfte Harmonie

Sanfte HarmonieMit Java 8 nimmt die Entwicklung von Frontends mit JavaFX langsam Fahrt auf. Sofern man nicht an einen bereits existierenden Swing-Client gebunden ist, gibt es eine Menge guter Gründe direkt mit JavaFX ins Rennen zu gehen. Neben vielen anderen Features besitzt vor allem das standardisierte (bidirektionale) Databinding eine gewisse Attraktivität, verspricht es doch den Wegfall manueller Synchonisationslogik. Angezogen von der charmanten Aura, mit der sich JavaFX umgibt, starte ich die ersten Clientprojekte. Sofort verliebe ich mich in FXML, freue mich über den aufgeräumten Code und stelle fest, dass Frontend-Entwicklung tatsächlich wieder Spaß macht. Bei der Integration meines Datenmodells über einen Servicelayer komme ich allerdings ins Stocken. Die Daten, die ich beziehe bekomme ich in Form von XML angeliefert. Alles ist präzise in einem XML-Schema spezifiziert und für mich ist JAXB das Mittel der Wahl. Die passend annotierten JavaBeans lasse ich mir mithilfe des xjc-Plugins im Build- Prozess generieren. Soweit so gut. Jetzt noch schnell das Databinding für mein JavaFX-Frontend vorgenommen und fertig? Leider nein! Das Plugin erzeugt mir dummerweise nur die „normale Ausbaustufe“ der zum XML-Schema gehörenden JavaBeans. Eine Variante, mit passenden JavaFX-Properties lässt sich das xjc-Tool beim Generieren leider nicht entlocken. Eine Suche im Internet liefert auch keine passende Lösung für mein Problem. Und so macht sich dann doch ein wenig Enttäuschung breit. Die ist aber nicht von langer Dauer, lässt sich die Codegenerierung des xjc-Tools doch mittels Plugin modifizieren. Entstanden ist ein xjc-Plugin, mit dessen Hilfe nun JavaBeans generiert werden können, die die benötigten JavaFX-Properties enthalten. JAXB und JavaFX-Databinding friedlich vereint, arbeite ich weiter an der Fertigstellung meiner Anwendung. Das Plugin freut sich indes in Form des GitHub-Projektes jaxbfx auf die Community. Bleibt mir nur ebenfalls viel Spaß auf der Clientseite zu wünschen!

FindBugs: May expose internal representation by returning reference to mutable object

Wer seine Code-Qualität mit FindBugs überwacht, stößt früher oder später auf folgende Verletzung: „Method-X may expose internal representation by storing/returning an externally mutable object into Field-Y“. In den meisten Fällen handelt es sich dabei um das Abfragen und Speichern von java.util.Date Werten.

Erfahrene Java-Entwickler wissen, dass Date-Objekte nachträglich veränderbar (mutable) sind:

Date now = new Date();
now.setTime(1414141414141L);
System.out.println(now);

Dies könnte für Manipulationen ausgenutzt werden:
weiterlesen

Graph-basierte Software-Analyse mit jQAssistant

Artikel als PDF herunterladen:
Download Graph-basierte Software-Analyse mit jQAssistant

Qualitätssicherung in der Software-Entwicklung ist seit Jahren ein Thema, mit dem es problemlos möglich ist, Zeitschriften, Bücher und Konferenzen inhaltlich zu füllen. Die Ansatzpunkte sind äußerst vielfältig – sie reichen von der Prozessorganisation über Teststrategien, technische Infrastrukturen bis hin zu vermeintlich trivialen Dingen wie der Formatierung des Quellcodes. In diesem Artikel möchte ich einen Aspekt beleuchten, der sich auf der Ebene statischer Code-Analysen abspielt: die Festlegung und Überwachung projektspezifischer Architektur- und Design-Regeln.

 

Verfallene Strukturen

Verfallene Strukturen

weiterlesen

buschmais Trainingswoche

jQAssistantWebreportsAlle aktuellen Projekte für eine Woche geparkt, im buschmais Büro werden Tische und Stühle zusammengerückt, Getränke in den Kühlschrank und los gehts: Trainingswoche@buschmais. Abseits vom Alltagsgeschäft stehen nun neue Technologien und Konzepte im Mittelpunkt. Thema diesmal: „Grafische Visualisierung für HTML mit JavaScript“ – wir bauen ein Webfrontend für jQAssistant.

Die Anforderungen waren schnell formuliert: In Zukunft soll jQAssistant dem Nutzer die Möglichkeit bieten, sich individuelle Metriken als Abfragen zu definieren und die Ergebnisse in Form einer TreeMap im Browser darzustellen.

Für unsere Realisierung haben es zwei Frameworks in die engere Wahl geschafft: Das JavaScript InfoVis Toolkit, kurz JIT, und das Data-Driven Dokuments Framework, kurz D3.js. Beides sind weit verbreitete JavaScript-Bibliotheken zur Visualisierung von konkreten Daten. Um zu ergründen, was hinter den markig daherkommenden Projektwebseiten steckt, arbeiteten wir in Teams, so dass wir beide Frameworks parallel integrieren und testen konnten. Die Entscheidung für D3.js und gegen JIT fiel erst am letzten Tag. Bis dahin hatten wir beide Frameworks als gleichwertig betrachtet, mit ein paar Stärken in einem und auch Schwächen in dem anderen Framework. Der letztendliche Entscheidungsfaktor war dann jedoch die „Unbestimmtheit der Datenmenge“ die der Nutzer den Frameworks zukommen lassen kann. Hier stießen wir aufgrund der rekursiven Implementierung der Render-Funktion auf Probleme im JIT. Diese Rekursion brachte ab einer Datenmenge von ca. 5000 Datensätzen den Browser dazu, die Verarbeitung abzubrechen.

Die Kommunikation des Browsers mit dem jQAssistent-, oder genauer gesagt dem Neo4J-Server, überlassen wir einem weiteren, weit verbreiteten JavaScript-Framework: AngularJS. Auch wenn die Einarbeitung in das Framework und der Umgang mit diesem anfangs recht schwierig, wenn nicht sogar müßig erschien (stellenweise fragten wir uns: „Warum eigentlich AngularJS und nicht pures JavaScript?“), hat es am Ende doch seine Stärken gezeigt. Mal abgesehen von der sauberen Trennung zwischen Model, View und Controller – was uns eine gute Parallelisierung der Arbeit ermöglichte – sind auch die gut abstrahierten AJAX-Calls ein großer Gewinn gewesen.

Als Resümee der Trainingswoche können wir sagen: Es hat Spaß gemacht! Wir haben mal wieder einen Blick über den Tellerrand geworfen und jQAssistant darf sich in Zukunft mit dem neuen Webfrontend schmücken. Wir sind schon gespannt welche Themen beim nächsten mal auf der Tagesordnung stehen.

 1 2 3 4 5 6 Vor