„Wenn es funktioniert, denken die Manager, dass es so gut wie erledigt ist.“

Die Softwareentwicklung konzentriert sich oft ausschließlich auf das Hinzufügen von Funktionen; für Themen wie Wartbarkeit, Architektur und Leistung bleibt keine Zeit. Das muss nicht schwierig sein, sagt Softwaretrainer Onno van Roosmalen, aber es gibt Missverständnisse über Agile, Architektur, UML, objektorientierte Programmierung und testgetriebene Entwicklung.

Modeln? So etwas machen wir nicht. Entwurfsmuster? Lassen wir ausfallen. Weil wir agil arbeiten. Onno van Roosmalen hört das regelmäßig: Agilität als Ausrede oder sogar als Vorwand, um Softwarearchitektur nicht ernst zu nehmen. Als Ausbilder im Bereich der Softwareentwicklung stellt er fest, dass es viele Missverständnisse in Bezug auf nicht-funktionale Anforderungen gibt: Architektur, Schnittstellen, Leistung, Modellierung, Wartbarkeit und so weiter.

Missverständnisse, die sich leicht erklären lassen, weil sie mit dem schwer fassbaren Konzept der ‚Softwarequalität‘ zu tun haben. „Qualität ist für viele Menschen nicht sichtbar“, sagt Van Roosmalen. „Wenn es funktioniert, dann funktioniert es und Manager, Kunden und Benutzer denken, dass es so gut wie fertig ist. Es wird sehr schwierig zu argumentieren, warum man etwas extra machen muss. In der Praxis erhalten die Entwickler jedoch eine klare Gegenleistung dafür.“

Viele dieser Missverständnisse über die Qualität von Software gibt es auch unter den Entwicklern selbst. Beliebte Softwaretechniken, wie die testgetriebene Entwicklung, tragen seiner Meinung nach nicht dazu bei: „Die testgetriebene Entwicklung konzentriert sich vollständig auf die Funktionalität. Aspekte, die typischerweise mit der Architektur verbunden sind, wie Leistung, Wiederverwendbarkeit, Erweiterbarkeit und Softwareevolution, sind sehr schwer zu testen. Genau wie Race Conditions und Deadlocks.“

„Es gibt auch die Vorstellung, dass Architektur etwas Abstraktes ist, das im Voraus erdacht werden muss, was dann die Richtung des Projekts in eine Zwangsjacke zwingt – eine Big-Bang-Architektur, die beim ersten Mal richtig sein muss. Aber das geht nicht. Oft weiß man nicht, was als nächstes kommt“, erklärt Van Roosmalen. „Natürlich ist es gut, eine Vorstellung davon zu haben, wie man es einrichten will. Aber manchmal sieht man, dass sich die Projekte bereits auf bestimmte Ergänzungen vorbereiten. Dann denke ich oft: Ja, und werden sie wirklich kommen?“

Außerdem verstaubt die zugrunde liegende Theorie mit der Zeit. Das merkt er zum Beispiel bei seiner Grundausbildung zum Thema Emergent Object-Oriented Design in the Age of AI (OOAD). Er trifft dort auf Teilnehmer mit einem elektrotechnischen Hintergrund, aber auch auf Leute, die einen IT-Abschluss erworben haben. „Man sieht jedoch, dass viele von ihnen Probleme prozedural statt objektorientiert analysieren“, sagt Van Roosmalen. „Das ist es, was sich einschleicht, wenn Menschen unter Druck Software entwickeln, während man in Wirklichkeit bemerkenswert bessere Software entwickeln kann, wenn man die Richtlinien richtig anwendet.“

‚In C# ist das nicht so‘

Van Roosmalen selbst hat einen ganz anderen Hintergrund: Er studierte Physik in Nijmegen und promovierte am Kernfysischen Versneller Instituut in Groningen. Dann ging er nach Amerika, um eine Postdoc-Stelle am California Institute of Technology anzutreten.

Der Wendepunkt kam im Jahr 1987. Van Roosmalen und seine Frau wollten eigentlich in die Niederlande zurückkehren, aber Jobs in der Physik waren nicht zu haben. Als an der Technischen Universität Eindhoven eine Stelle im Bereich der technischen Informatik frei wurde, beschloss Van Roosmalen, diese Gelegenheit zu nutzen; seine Arbeit auf dem Gebiet der Computerphysik hatte sein Interesse an Software und Computern geweckt.

Außerdem stellte Van Roosmalen fest, dass er gerne unterrichtete. Vor seiner Rückkehr in die Niederlande hatte er bereits drei Jahre lang in Yale gelehrt, und als Anfang der neunziger Jahre objektorientierte Techniken aufkamen, begann er mit der Schulung von Unternehmen. Nach der Jahrtausendwende beschloss er, seine Beschäftigung bei der TUE zu reduzieren, um sich schließlich ganz auf die Ausbildung zu konzentrieren. Er arbeitet immer noch für die Universität Eindhoven, die ihn für den PDEng-Kurs in Softwaretechnologie anheuert.

Deshalb bietet Van Roosmalen auch Schulungen für Entwickler an, die schon ein paar Jahre in einem Unternehmen beschäftigt sind. Er stellt einen großen Unterschied bei den Anfängern fest: Je länger die Entwickler hinter der Tastatur verbracht haben, desto empfänglicher sind sie im Allgemeinen für fortgeschrittene Konzepte der Softwaretechnik. „Man fängt an, die Dinge auf eine andere Art und Weise zu betrachten und ich glaube, man sieht die Dinge mehr im Zusammenhang. Es bleibt ein bisschen besser haften.“

„In den meisten objektorientierten Programmiersprachen können Objekte derselben Klasse zum Beispiel direkt auf die privaten Attribute der anderen zugreifen. Die Leute wissen das oft gar nicht. Dann probieren sie es aus, und es stellt sich heraus, dass es stimmt. Sie sagen dann oft etwas wie: ‚Aber in C# ist das nicht so.‘ Und dann stellt sich heraus, dass es dort genau so ist“, gibt Van Roosmalen als Beispiel an. „Es scheint elementar zu sein, aber es stecken wichtige Ideen dahinter, und die meisten Entwickler sprechen gerne wieder darüber. In den meisten Schulungen geht es um den Prozess und all das, und nicht um die technischen Dinge.“

Defensiv

„Genau dieses Wissen über Objektorientierung bildet die Grundlage für einen Großteil der Architektur einer typischen Anwendung. Das bedeutet, dass Sie automatisch mit wichtigen Softwareeigenschaften wie dem Verstecken von Informationen und der Kapselung konfrontiert werden, d.h. der Idee, dass Sie Informationen lokalisieren und nicht durch das gesamte System werfen. In der Praxis erleben Sie regelmäßig, dass ein Team eine Komponente mit zusätzlichen Funktionen ausstattet und dann das gesamte System wie Dominosteine umkippt. Das macht es problematisch, etwas hinzuzufügen. Bei vielen Webanwendungen sieht man, dass diese Idee ein wenig kaputt ist“, sagt Van Roosmalen.

Und dann geht das Verstecken von Informationen Hand in Hand mit dem Mittel, über das die Komponenten miteinander kommunizieren: die Schnittstelle oder API. „Sie ermöglicht es Ihnen, die detaillierte Form Ihrer Objekte zu verbergen und sicherzustellen, dass keine Implementierungsdetails nach außen dringen. Sie sorgen also dafür, dass der Client-Code nur das tun kann, was gerade angefordert wird, nicht mehr und nicht weniger“, erklärt Van Roosmalen.

Die Idee dahinter ist, dass die Entwicklung von Komponenten auf diese Weise entkoppelt werden kann. Wenn eine neue Version einer Komponente weiterhin das tut, was sie früher über eine Schnittstelle getan hat, muss die darauf aufbauende Software nicht sofort geändert werden. Ein Entwicklungsteam, das gegen die Komponente programmiert, kann die neue Version gefahrlos verwenden, ohne Angst haben zu müssen, dass dabei etwas umkippt. Wenn Kapselung und Schnittstellen in Ordnung sind, wird fast automatisch eine wartbare, skalierbare Architektur geschaffen, die mit der Anwendung wachsen kann.

Dies erfordert jedoch, dass die Teams bei der Gestaltung ihrer Schnittstellen eine defensive Haltung einnehmen. „Sie sollten nicht einfach alles anbieten, was andere Teams verlangen. Je mehr Sie anbieten, desto mehr unbeabsichtigte Nutzungen gibt es. Das erhöht die Wahrscheinlichkeit, dass die Dinge mit einer neuen Version umfallen. Sie können eine Schnittstelle später immer noch erweitern, aber eine Verkleinerung ist viel schwieriger“, sagt Van Roosmalen.

„Ich habe dafür einen sehr schönen Workshop, den ich mit den TUE-Azubis durchführe. Mehrere Teams erhalten die Aufgabe, eine Komponente mit einer Schnittstelle zu entwickeln. Danach müssen sie eine funktionale Erweiterung dazu machen – natürlich unerwartet; das halte ich geheim. Dann müssen sie versuchen, für die Komponenten der anderen Teams Testfälle zu erstellen, die gegen die erste Variante funktionieren, aber nicht mehr gegen die zweite. Das sind echte Augenöffner, denn oft sind solche Tests im Handumdrehen gemacht.

Trickkiste

Die Entwickler müssen das Rad nicht jedes Mal neu erfinden. Für viele Probleme haben sich im Laufe der Jahre bewährte Verfahren in Form von Mustern herausgebildet. „Sie können zum Beispiel Ihre Architektur in Schichten aufbauen: Das ist ein Architekturmuster. Um diese Schichten zu strukturieren, verwenden Sie verschiedene Entwurfsmuster.“

Van Roosmalen bietet einen Schulungskurs an, der ganz diesem Thema gewidmet ist: Design Patterns und Emergente Architektur. Das ist natürlich sehr weit gefasst, aber die Idee dahinter ist vor allem, zu zeigen, dass Sie diese Trickkiste haben. „Eigentlich ist das eine meiner Lieblingsschulungen, weil man wirklich über Softwaredesign spricht und weil man damit alle möglichen praktischen Probleme angehen kann. Es geht auch um ganz andere technische Aspekte, wie z.B. Zustandsautomaten mit möglichen Deadlocks.“

Van Roosmalen bietet zusammen mit einem ehemaligen TUE-Kollegen auch einen Folgekurs zu einem anderen Architekturthema an: Echtzeitverhalten. In der Regel geht es um Probleme mit Systemen, die mehrere gleichzeitige Aufgaben ausführen müssen, die zeitlichen Anforderungen unterliegen. Heutzutage ermöglichen die meisten modernen Programmiersprachen die Programmierung von Gleichzeitigkeit, und das führt zu ganz speziellen Problemen wie Race Conditions und Deadlocks.

Auch hier geht schon bei den Grundlagen einiges schief, bemerkt Van Roosmalen: „Viele Leute, die Probleme mit Echtzeit haben, verwenden ein Betriebssystem wie Microsoft Windows. Nun, das ist kein Echtzeit-Betriebssystem. Es enthält zwar viele Dinge wie Echtzeitprioritäten und so weiter. Aber es fehlen viele andere Dinge, die ebenfalls für Echtzeitverhalten notwendig sind. Dann müssen Sie sich ein bisschen auf den Kopf stellen, um es richtig zu machen.“

„In Echtzeitsystemen gibt es zum Beispiel das Problem der Prioritätsumkehrung, bei der eine Aufgabe mit niedriger Priorität eine Ressource beansprucht, so dass Aufgaben mit höherer Priorität sie nicht nutzen können. Es gibt Mechanismen, um dies auf ein Minimum zu beschränken, und sie müssen im Betriebssystem enthalten sein.“

Bindung an den Lieferanten

Van Roosmalen bietet auch eine grundlegende Schulung zu SysML, einer Variante von UML für die Systemtechnik. Systemingenieure modellieren viel, doch SysML wird in der Praxis nur spärlich eingesetzt. Dafür gibt es einen Grund: „Für die Systemtechnik werden viele kommerziell erhältliche Tools wie Matlab und Simulink verwendet. Diese liefern keine standardisierten Modelle. Das wollen die Anbieter von Werkzeugen ohnehin nicht, denn sie könnten ihr Geschäft verlieren. Sie setzen auf Vendor Lock-in.“

Aber mit SysML können Sie diese Modelle dennoch miteinander integrieren und ein übergreifendes Modell Ihres Systems erstellen. Die OMG, die Standardisierungsgruppe hinter SysML, hat versucht, diese Modellierungstechniken so zu kombinieren, dass das Ganze alles abdeckt und gleichzeitig methodisch solide ist. „Das hat ziemlich gut funktioniert, aber es macht die Modellierungssprachen furchtbar groß.“

Van Roosmalen ist der Meinung, dass Softwareentwickler die Modellierung ebenfalls etwas ernster nehmen sollten. In seinen Kursen stützt er sich selbst stark auf die UML – zum Teil, weil eine Schulung zu kurz ist, um sich ausführlich mit der Programmierung zu befassen, auch wenn Programme als Proof of Concept zur Verfügung gestellt werden. Aber auch, weil sie gute Ansatzpunkte bietet, um über die Klassenstruktur nachzudenken und die Architektur zu überdenken.

„Was die UML betrifft, so haben die meisten Softwareentwickler sie schon einmal gesehen, aber die Schwelle, um wirklich damit anzufangen, ist ziemlich hoch. Die Erstellung eines guten Modells erfordert wirklich eine Investition, bevor sie sich auszahlt“, stimmt Van Roosmalen zu. Außerdem mangelt es Softwareentwicklern ein wenig an der Disziplin, die Systementwickler haben, stellt er fest.

Aber das ist wiederum ein Symptom dafür, dass Qualität bei Software schwer zu erkennen ist und sich erst langfristig bemerkbar macht, während das bei der Systemtechnik natürlich anders ist. „Für Programmierer ist es daher wichtig, die Qualität auf die Karte zu setzen. Und im Gegensatz zu dem, was man manchmal denkt, kann Agile dabei helfen“, sagt Van Roosmalen: „Das Agile Manifest besagt einfach, dass man der Softwarequalität Aufmerksamkeit schenken muss. Es enthält sehr vernünftige Aussagen dazu, aber man muss das, was dort gepredigt wird, auch in die Praxis umsetzen.“

Dieser Artikel wurde von Pieter Edelman geschrieben, Tech-Redakteur von Bits&Chips.