Tag: agile software engineering (Seite 2 von 2)

Software Reverse Engineering

er Softwaremarkt ist in vielen Bereichen hart umkämpft. Es existieren viele Mitbewerber und unzählig viele Produkte in den verschiedensten Bereichen. Um sich als Firma durchzusetzen und einen möglichst hohen Marktanteil zu ergattern, muss sich eine Software in der Regel von den Konkurrenzprodukten absetzen. Ich denke dabei an Innovationen: Besondere Funktionalität und sehr ausgeklügelte Lösungsansätze, aber auch an Performance-Erwartungen.

Um diesen Vorsprung zu erreichen, muss ein Unternehmen viel investieren. Es ist notwendig Fachleute anzustellen und die Entwicklung und Umsetzung des Konzepts benötigt mehr oder weniger Zusatzaufwand. Es müssen Tests gefahren werden, die den ordentlichen Betrieb dieser Neuerung gewährleisten. All dies führt zu Kosten, die dann (so die Erwartung) durch den besseren Absatz gedeckt werden können.

Je mehr Entwicklungsaufwand betrieben wird und je mehr es beim Vertrieb auf diese Innovationen ankommt, desto mehr sollte man sich die Frage stellen, wie diese Software zu schützen ist. Dieser Blogeintrag soll einen Denkanstoß in diese Richtung geben. Dabei geht es nicht um einen Kopierschutz, sondern um die Gefahren und den Schutz vor ungewollten Einblicken durch die Konkurrenz mittels Software Reverse Engineering.

Behavior Driven Development

n Projekten kommt es immer wieder vor, daß Kunden und Business Analysten bei der Präsentation der Ergebnisse einer Softwareentwicklung ihre Anforderungen nicht umgesetzt sehen. Gründe dafür können z.B. unspezifische Anforderungen, fehlende Beispielfälle und Mißverständnisse bei der Interpretation der Anforderungen sein. Softwareentwickler leiten aus der sprachlichen Spezifikation Testfälle in Programmcode ab, die von technikfernen Projektbeteiligten nur schwer verstanden und geprüft werden können. Wie kann es ermöglicht werden, diese automatischen Tests lesbarer zu gestalten, so daß sie durch Business Analysten und Kunden geschrieben und abgenommen werden können? Bei der Suche nach Lösungen bin ich auf “Behavior Driven Development” gestoßen.

Inversion of Control

Vergleichbar mit der Konstruktion eines Wolkenkratzers, müssen bei der Erstellung einer Software Architektur-Richtlinien definiert und berücksichtigt werden. Wird dies nicht befolgt, stürzt die Konstruktion über kurz oder lang ein.
Inversion of Control gibt dem Entwickler ein effektives Tool an die Hand, um Software auf Klassenebene so solide zu bauen, dass auch bei größeren Umbaumaßnahmen oder langjähriger Weiterentwicklung die Architekturaspekte Erweiterbarkeit, Wiederverwendbarkeit, Testbarkeit nicht in Mitleidenschaft geraten.

Automatisierte Tests über Weboberflächen

Fast jeder kennt das Problem. Man implementiert neue Funktionalität, führt eventuell noch paar Code-Optimierungen durch und lässt anschließend Unit-Tests laufen. Obwohl alle Tests erfolgreich sind, ist man trotzdem nicht immer sicher, ob eigene Änderungen keine Seiteneffekte verursacht haben, die erst beim manuellen Testen der Applikation über die Oberfläche ersichtlich werden. Ganz schlimm wird es, wenn diese Fehler ganz übersehen werden. Meistens ist es nicht der Fall. Doch wer sicher sein will, sollte sich über Testautomatisierung der Benutzeroberflächen (GUI-Testing) Gedanken machen.

Legacy Code unter Kontrolle – Folge 3, JMockit für Fortgeschrittene

m ersten Blog-Eintrag dieser kleinen Serie habe ich erzählt, warum JMockit eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung zu testen. Im nächsten Eintrag habe ich das wichtigste API von JMockit, das Expectations-API vorgestellt. Als Abschluss zeige ich an zwei konkreten Beispielen aus der Praxis, wie JMockit einem auch in schwierigen Fällen einen Unit-Test möglich macht.

Hier nochmal der Überblick über die ganze Serie:
•    Folge 1: Vorstellung von JMockit
•    Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur schwer zu erstellen wäre.
•    Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Schaltjahresproblem und ein Singleton-Factory-Lindwurm.

Legacy Code unter Kontrolle – Folge 2, Die Grundkonzepte von JMockit

In meinem letzten Blog-Eintrag habe ich erläutert, warum JMockit bei meinem aktuellen Kunden eine so wichtige Rolle spielt, wenn es darum geht, eine Legacy-Anwendung testbar zu machen und so änderbar zu halten.
In der Folge 2 will ich heute darstellen, wie man konkret Unit-Tests mit JMockit schreibt und welche Konzepte dabei eine Rolle spielen. Es entsteht ein Test für eine Stück Legacy Code, das ohne JMockit nur sehr schwer zu testen wäre.

Hier nochmal der Überblick über die ganze Serie:

  • Folge 1: Vorstellung von JMockit
  • Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur sehr schwer zu erstellen wäre.
  • Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Remote-Service-Call und eine Schaltjahresregelung.

Legacy Code unter Kontrolle Folge 1 Vorstellung von JMockit

Bei meinem aktuellen Kunden setzen wir das Tool „JMockit“ so erfolgreich ein, dass es inzwischen einen wichtigen Platz in meiner „virtuellen Werkzeugkiste“ bekommen hat. Auch wenn sich die Entwickler in meinem Team größte Mühe gegeben haben, ordentlichen Code mit einem sauberen Design zu erstellen, so schlagen wir uns nun dennoch durch inzwischen weit über 1 Million Zeilen Java-Code, aus denen uns die Fehlentscheidungen der letzten 10 Jahre „entgegenmüffeln“. Wir kämpfen mit Legacy Code. Hier helfen uns Unit-Tests. Und JMockit spielt bei der Erstellung dieser Tests eine entscheidende Rolle.

 

Da JMockit noch recht neu und unbekannt ist, möchte ich es Ihnen hier in einer lockeren Folge von Blog-Einträgen näherbringen:

  • Folge 1: Vorstellung?
  • Folge 2: Die Grundkonzepte von JMockit. Ein erster Test, der ohne JMockit nur sehr schwer zu erstellen wäre.
  • Folge 3: Zwei schwierige Fälle aus der Praxis: Ein Remote-Service-Call und eine Schaltjahresregelung.