Naked Objects

Grundidee und Funktionsweise

Naked Objects ist ein Architekturmuster der Softwaretechnik. Es organisiert eine Anwendung um ihre Fachobjekte, also Objekte, die zentrale Begriffe und Regeln des jeweiligen Anwendungsbereichs darstellen. Das Muster beruht auf drei Prinzipien:

• Die gesamte Geschäfts- beziehungsweise Fachlogik wird in den Fachobjekten gekapselt. Kapselung bedeutet, dass Daten und die dazugehörigen Regeln und Operationen in denselben Objekten zusammengefasst werden.
• Die grafische Benutzeroberfläche stellt die Fachobjekte direkt dar. Benutzeraktionen bestehen ausdrücklich darin, Fachobjekte zu erstellen oder abzurufen und Methoden dieser Objekte aufzurufen.
• Die Benutzerschnittstelle wird zu 100 % automatisch aus der Definition der Fachobjekte erzeugt. Dafür können verschiedene Techniken einschließlich Source-Code-Generierung eingesetzt werden; bisherige Implementierungen bevorzugen Reflexion, also die Untersuchung von Klassen und Objekten zur Laufzeit.

Die ersten beiden Prinzipien verbinden eine konsequente Datenkapselung mit einer objektorientierten Benutzeroberfläche (OOUI). Entscheidend für Naked Objects ist ihre Kombination mit der vollständig automatischen Erzeugung der Oberfläche. Dadurch werden Fachlogik und Darstellungslogik klar getrennt, was insbesondere das Single-Responsibility-Prinzip unterstützt: Ein Bestandteil des Systems soll jeweils nur eine klar abgegrenzte Verantwortung besitzen.

Das Muster wurde 2001 auf der OOPSLA-Konferenz von Richard Pawson und Simon Dobson unter dem Titel „Expressive Systems: A Radical Approach to Business Systems Design“ vorgestellt und später von Pawson in seiner Dissertation ausführlich beschrieben. Naked Objects wird häufig mit Model View Controller (MVC) verglichen. Trygve Reenskaug, der Erfinder von MVC, schrieb im Vorwort der Dissertation, Naked Objects stehe der ursprünglichen MVC-Idee näher als die meisten MVC-Interpretationen und -Implementierungen.

Ziele und Nutzen

Naked Objects soll die Erhebung von Anforderungen verbessern. Da Fachklassen und ihre Funktionen unmittelbar auf der Benutzeroberfläche sichtbar sind, können Anwender, Analytiker und Entwickler leichter eine gemeinsame „Ubiquitäre Sprache“ verwenden. Dieser Begriff bezeichnet ein einheitliches Fachvokabular, das alle Beteiligten benutzen. Zusammen mit den weiteren Eigenschaften des Musters erleichtert dies die gemeinsame Entwicklung funktionaler Prototypen mit den Anwendern.

Die Softwareentwicklung soll produktiver werden, weil das meist manuelle und häufig schwierige Mapping zwischen grafischer Benutzeroberfläche und Fachlogikschicht entfällt. Pawsons Dissertation vergleicht dazu zwei Implementierungen derselben Anwendung: eine mit einer konventionellen vierschichtigen Architektur und eine auf Grundlage von Naked Objects.

Fachliche Änderungen lassen sich schneller umsetzen, weil Fachlogik und Eingabelogik getrennt sind. Eine geänderte Anforderung muss daher nicht zusätzlich in einer eigenständig programmierten Benutzeroberfläche nachvollzogen werden. Dies kann agile, also schrittweise und anpassungsfähige Entwicklungsprozesse unterstützen. Umstritten ist allerdings, ob noch von agiler Entwicklung gesprochen werden kann, wenn Prozesse und Methoden fest modelliert werden. Dahinter steht die Kontroverse zwischen opportunistischen agilen Methoden und strategischen, formalen Ansätzen des Domain Engineering.

Ein weiteres Ziel ist eine höhere Qualität von Architektur und Fachlogik. Erforderlich ist ein Domänenmodell, also ein Modell der fachlichen Begriffe und Regeln, das sich 1:1 auf die Benutzeroberfläche abbilden lässt. Dadurch soll das Modell tatsächlich den Benutzeranforderungen entsprechen. Die erzwungene Trennung von Fach- und Eingabelogik verbessert außerdem die Änderbarkeit und Wartbarkeit der Anwendung; die behauptete Förderung der Agilität gilt jedoch nur unter dem genannten Vorbehalt.

Aus dem Domänenmodell entstehen automatisch objektorientierte Benutzeroberflächen. Sie ermöglichen insbesondere Interaktionen im Hauptwort-Zeitwort-Stil: Zuerst wird ein Objekt ausgewählt, danach eine auf dieses Objekt anzuwendende Handlung. Dies steht dem sonst häufigen Zeitwort-Hauptwort-Stil gegenüber.

Grenzen und Kritik

Die erzeugten objektorientierten Benutzeroberflächen eignen sich vor allem für sogenannte souveräne Applikationen. Das sind Anwendungen, die die Aufmerksamkeit der Benutzer über längere Zeit beanspruchen. Für transiente Applikationen sind sie dagegen ungeeignet. Damit sind kleine Anwendungen für einzelne, vorübergehende Anforderungen gemeint, beispielsweise Installer, Taschenrechner oder alleinstehende Dialoge.

Außerdem wird bezweifelt, dass eine automatisch erzeugte objektorientierte Oberfläche den tatsächlichen Ansprüchen der Benutzer immer gerecht werden kann. Diese Kritik betrifft nicht ausschließlich Naked Objects, sondern auch die einzelnen Konzepte, die das Muster miteinander verbindet.

Kontrovers ist zudem das Verhältnis zur agilen Softwareentwicklung. Befürworter sehen Vorteile durch iterative Umsetzung und die frühe Beteiligung der Anwender. Vertreter von Requirements Engineering und Domain Engineering argumentieren dagegen, dass stark ausgearbeitete funktionale System- und Domänenbeschreibungen mit Methoden wie XP oder Scrum im Widerspruch stehen können. Einige Fachexperten halten professionelles Requirements Engineering deshalb sogar für unvereinbar mit diesen agilen Methoden. Der Artikel stellt somit gegensätzliche Auffassungen dar, ohne die Kontroverse aufzulösen.

Praktischer Einsatz

Der vermutlich erste operationale Einsatz erfolgte im November 2002 beim irischen Department of Social and Family Affairs, dem Sozialministerium. Dort wurde unter anderem eine Enterprise-Anwendung zur Verwaltung von Kinderbeihilfen mit Naked Objects umgesetzt. Richard Pawson verarbeitete die Erfahrungen und die Reaktionen der Anwender in seiner Dissertation.

Positiv bewertet wurde besonders, dass sich die Fachobjekte über mehrere Anforderungsbereiche hinweg wiederverwenden ließen. Die anfängliche Naked-Objects-Architektur stammte von Fujitsu. Später wurde die Anwendung auf das Open-Source-Framework Naked Objects for Java portiert und weiterentwickelt.

Verwandte Ansätze

Objektorientierte Persistenzmechanismen ergänzen Naked Objects auf der Datenseite. Persistenz bezeichnet die dauerhafte Speicherung von Objektdaten. Techniken wie objektrelationale Abbildung oder Objektdatenbanken ersetzen die Datenzugriffsschicht unterhalb der Fachobjekte. Zusammen mit Naked Objects entsteht damit eine konsequent auf Fachobjekte ausgerichtete Architektur, in der das Single-Responsibility-Prinzip umfassend umgesetzt werden kann.

Auch zur agilen Softwareentwicklung bestehen Berührungspunkte. Einige Gruppen sehen Naked Objects als Unterstützung für iterative Entwicklung und für die Beteiligung der Anwender an der Anforderungserhebung. Die Umsetzung im irischen Sozialministerium lieferte nach dieser Auffassung positive Erfahrungen. Die Gegenposition betont, dass Requirements Engineering (RE) und Systems Engineering (SE) ein zunächst eher nicht-funktionales Konzept schrittweise zu einer funktionalen Systembeschreibung weiterentwickeln sollen, die implementiert, gemessen, getestet, angewendet und verbessert werden kann. Dieser Vorgang wird als Konzeptionalisierung bezeichnet. Eine solche formale Entwicklung kann den Bedarf an agilen Methoden verringern und wird daher teilweise als Gegensatz zu Scrum oder XP betrachtet.

Domain-driven Design (DDD) ist im Unterschied zu Naked Objects kein Architekturmuster, sondern eine Vorgehensweise zur Modellierung der Fachlogik. Beide Ansätze verlangen, die gesamte Fachlogik in Fachobjekten abzubilden. DDD fordert jedoch nicht, dass die Benutzerschnittstelle eine direkte Darstellung dieser Objekte sein muss. Naked Objects kann die Umsetzung von DDD erleichtern, weil es das Domänenmodell für Anwender und Analytiker sichtbar macht und damit die von DDD geforderte Ubiquitäre Sprache fördert.

Verfügbare Frameworks

Frameworks stellen technische Grundstrukturen bereit, mit denen Anwendungen nach dem Naked-Objects-Muster entwickelt werden können. Der Artikel nennt Implementierungen für mehrere Programmiersprachen:

• Java: OpenXava; NoWicket, ein Open-Source-Framework für Webanwendungen auf Basis von Apache Wicket; gengui für Swing-Anwendungen; Domain Object Explorer; JMatter für Business-Anwendungen von Arbeitsgruppen; Apache Isis; Sanssouci; Tynamo; sowie Lablz – Data objects as Web Applications.
• .NET: dotObjects, Naked Objects for .NET und TrueView for .NET.
• C++: Typical Objects for C++.
• PHP: NakedPhp.