Dienen Modelle der Lösung von Problemen der IS Anwendungsentwicklung?

Rechnerunterstützte Informationssysteme sind aus der modernen Wirtschaft nicht mehr wegzudenken. Sie sind so weit verbreitet, dass es wohl keinen Geschäftsbereich mehr gibt, der nicht durch IS Anwendungen unterstützt wird. Aber die Erstellung von IS Anwendungssystemen ist immer noch eine relativ junge Wissenschaft. Das wird einem ziemlich schmerzlich bewusst, wenn man die in kleinen aber auch in großen Firmen momentan eingesetzten Anwendungssysteme etwas näher betrachtet. Das schließt sogar bekannte und weitverbreitete sogenannte "Standard Anwendungssysteme" für Unternehmen mit ein.

Die meisten der aktuell eingesetzten kommerziellen IT Anwendungssysteme, die zur Steuerung und Verwaltung von Unternehmen verwendet werden, sind charakterisiert durch einen relativ geringen Integrationsgrad und eine relativ große Überlappung (Redundanz) von Funktionen und Daten. Das kommt daher, dass der Basisentwurf für die meisten Anwendungssysteme aus der Zeit stammt, in der die Leistungsfähigkeit der Rechner, gemessen an der Anzahl ausgeführter Rechenoperationen pro Zeiteinheit und gemessen an der verfügbaren Speicherkapazität, noch sehr begrenzt war. Darum war Stapelverarbeitung auch die Technik, mit der die Verantwortlichen für den Systementwurf und der Standardprogrammierer vertraut waren. Als dann größere Rechnerleistungen zur Verfügung standen, wurden die bestehenden Anwendungen durch Schnittstellenprogramme für den Datenaustausch miteinander verbunden und benutzerfreundlichere Endbenutzerschnittstellen (sogenannte GUIs - graphical user interfaces) für die Dateneingabe wurden vor die Anwendung gesetzt. Nichtsdestotrotz blieb aber der Grundaufbau der Anwendungen immer noch stapelverarbeitungsorientiert und daran hat sich bis jetzt nichts grundlegendes geändert.

Heutzutage sind Computer sehr mächtig und relativ billig geworden. Darum ist dezentralisierte aber trotzdem kooperative Verarbeitung unter Verwendung von verteilten Datenbanken wirtschaftlich geworden. Klienten auf Personalcomputern, sehr häufig Programme in der Rolle als speziell angepasste Endbenutzerschnittstelle mit gefälliger Oberfläche und mit einem hohen Grad an eigener Intelligenz, die die von Servern (im Netzwerk oder "Peer to Peer") angebotenen Dienste (Services) nützen, können nun in IT Anwendungssystemen mit verteilter Verarbeitung ökonomisch gerechtfertigt werden. Parallelverarbeitung ist verfügbar, um große Datenmengen in akzeptabler Zeit zu verarbeiten und das Internet kann benutzt werden, um netzbasierende Anwendungen praktisch weltweit verfügbar zu machen.

Andererseits sind in vielen Industrien zum wirtschaftlichen Überleben wirkliche Echtzeitsysteme für Entscheidungshilfen notwendig geworden, die auf die aktuellsten konsolidierten Informationen zugreifen, die im Unternehmen verfügbar sind. Viele der gegenwärtigen IT Anwendungssysteme können diesem Anspruch nicht genügen und es ist in den meisten Fällen auch nicht möglich, diese Anwendungsysteme mit wirtschaftlich vertretbarem Aufwand (gemessen in Zeit und Geld) auf diese neuesten ("state of the art") Techniken umzustellen, obwohl immer wieder der Versuch dazu unternommen wird. Ich persönlich glaube, dass die meisten (möglicherweise alle) Re-Engineering Versuche nicht die in sie gesetzten Erwartungen in Punkto Integration, Stabilität, Anpassungsfähigkeit, Erweiterungsfähigkeit und Wartbarkeit erfüllen, und dass der eingebrachte Aufwand (sofern er nicht beschönigend erfasst worden ist) nicht gerechtfertigt ist.

Dies bedeutet eine hohe Verpflichtung und Bürde für alle Entwickler von IT Anwendungssystemen. Sie müssen moderne, hochintegrierte und redundanzfreie Anwendungen entwickeln, und das in sehr kurzer Zeit, damit veraltete Anwendungssysteme baldmöglichst abgelöst werden können und so deren Wartungskosten möglichst frühzeitig wegfallen. Die neuen Anwendungen sollten so entworfen werden, dass sie den bestehenden Anwendungen überlegen sind und zwar insbesondere aus geschäftlicher Perspektive besonders langlebig sind. Das schließt insbesondere mit ein, dass sie - sofern erforderlich - sehr leicht anpassbar sind an zukünftige, neue geschäftliche aber auch EDV-technische Aspekte.

Dieses Ziel kann nur erreicht werden, wenn Anwendungsentwicklung in einer sehr disziplinierten Art und Weise durchgeführt wird und indem alle Techniken verwendet werden, die eine präzise Definition der angepeilten Ziele ermöglichen.

Darum wird in diesem Dokument vorgeschlagen modellbasierte Anwendungsentwicklung als besonders effiziente Technologie zur Entwicklung von neuzeitlichen, hochintegrierten kommerziellen IT Anwendungssystemen einzusetzen.
Der Zweck dieses Dokumentes ist zu erläutern, was ich darunter verstehe, wenn ich von Anwendungsentwicklung spreche. Das Dokument soll zeigen, was Modelle enthalten sollten, wie sie strukturiert sein sollten und wie die Information gesammelt werden sollten, die in einem Modell abgelegt werden.
Das Dokument zeigt ebenfalls, dass Projekte, die konsequent "modellbasierte Anwendungsentwicklung" verwenden, in Punkto Dauerhaftigkeit und Konsistenz bessere Resultate erbringen als alle anderen, mir bekannten Entwicklungsmethoden.

Über was ich schreibe - Einige Definitionen

Wenn eine gewisse Terminologie in einem bestimmten Kontext verwendet wird, dann ist es immer sehr sinnvoll, genau zu definieren, was mit den einzelnen Ausdrücken gemeint ist. Es kann eine Menge Verwirrung erzeugt werden, wenn Menschen miteinander reden und dabei meinen, dass der jeweils Andere mit den verwendeten Ausdrücken und ihrer Bedeutung vertraut sei, in Wirklichkeit jede Partei aber etwas unterschiedliches vor Augen hat. Wenn zum Beispiel ein Deutscher von einem "Handy" redet, dann meint er damit ein "Mobiltelefon", ein Amerikaner versteht darunter aber etwas Nützliches oder leicht erreichbares. Im Dokument sind schon einige Begriffe wie z.B. "Modell" oder "Anwendungsentwicklung" verwendet worden und es werden noch weitere Begriffe auftauchen. Ich möchte darum zuerst diese Begriffe definieren, und zwar so, wie sie in diesem Dokument verstanden werden.

Anwendungsentwicklung - was hier darunter verstanden wird und wie sie durchgeführt wird!

Wenn ich in diesem Dokument über Anwendungsentwicklung spreche, dann spreche ich über die Entwicklung von "kommerzieller Anwendungssoftware", also der Entwicklung von Anwendungssystemen zur informationstechnischen Unterstützung von Geschäftsvorgängen. Natürlich muss auch andere Software entwickelt werden, aber die Entwicklung von Computerspielen oder Computerwerkzeugen wie etwa Datei-Editoren oder auch die Entwicklung von sogenannter "Middle-Ware" oder selbst die Entwicklung von Betriebssystemen kann (zumindest während bestimmter Entwicklungsphasen) ziemlich verschieden zur Entwicklung kommerzieller Software sein. Das bedeutet nicht, dass ich meine, dass Personen, die mit der Entwicklung "nicht kommerzieller Software" betraut sind, hier zu lesen aufhören sollten.

Der Begriff "Anwendungsentwicklung" deckt in diesem Dokument den ganzen Prozess der Computersoftwareerstellung ab, und zwar beginnend mit der Dokumentation der ersten Idee über ein neues Softwareprodukt bis zur Zurückziehung eines nicht mehr benutzten Produktes aus dem Markt.

Im Wesentlichen gibt es zwei Verfahren, die benützt werden, kommerzielle Software zu entwickeln:

• Das funktions- und datenorientierte Verfahren mit seinen verschiedenen Ausprägungen. Diese Verfahren sind seit langer Zeit akzeptiert und sie werden praktisch benutzt, seit Anwendungsentwicklung ein ernsthaftes Geschäft geworden ist.

  und

• das objektorientierte Verfahren (zu einem gewissen Teil ebenfalls datenzentrisch), das in den späten sechziger Jahren erstmalig auftauchte, und das eine relativ schwierige Kindheit durchgemacht hat. Das Verfahren wurde in den späten achtziger Jahren hauptsächlich im Bereich der Entwicklung von graphischen Endbenutzerschnittstellen stärker beachtet. Es ist nun ziemlich ausgereift und ist darum durchaus auch ein Kandidat, um in der kommerziellen Anwendungsentwicklung angewandt zu werden.

Der Entwicklungsprozess - so wie ich ihn weiter oben definiert habe - ist ziemlich komplex, weil er eine Menge von Aktivitäten umfasst, die in einer gewissen Reihenfolge ausgeführt werden müssen. Der Prozeß muß daher strukturiert werden, damit er effizient durchgeführt werden kann. Wieder gib es im Wesentlichen zwei Strukturierungsmethoden:

1. das sogenannte "Wasserfall Modell" das bestimmte wichtige Ereignisse im Laufe des Entwicklungsprozesses (sogenannte "Meilensteine" oder anglizistisch "Checkpoints") definiert,

und

2. das "Spiralmodell" oder auch das "Fontänenmodell", das der Philosophie eines iterativen Entwicklungsverfahrens folgt.

Darüber, welches das bessere Verfahren sei, haben Experten schon wahre Religionskriege ausgefochten. Einige Argumente für die Art der Strukturierung, die ich bevorzuge und darum auch empfehle, will ich später noch diskutieren.

Modelle und Problemdomänen

Der Begriff "Modell" ist sehr vielfältig und es gibt darum eine Unzahl von Modelltypen. Bevor ich also detaillierter über Modelle schreibe, muss ich zuerst erklären was ich im Kontext dieses Dokumentes unter "Modell" verstehe.

Im Allgemeinen ist ein Modell eine Replik, also eine Nachbildung oder auch Abbildung eines realen Originals. Weil es aber nur eine Abbildung ist, zeigt es nur eine gewisse Auswahl der Eigenschaften des Originals.
Wenn ich von einem "Modell" rede, dann tue ich das im Sinne einer Abbildung eines Geschäftsfeldes und zwar aus der Sicht eines IS Anwendungsentwicklers. Darum gilt im Kontext dieses Dokumentes:

Ein "Modell" ist die Beschreibung einer bestimmten Sicht auf eine in der tatsächlichen Welt existierenden "Problem Domäne". Diese Beschreibung (Spezifikation) enthält die Gesichtspunkte, die einem Beobachter dieser Domäne aus seinem Betrachtungswinkel wichtig erscheinen.

In dieser Definition habe ich nun den Begriff der "Problem Domäne" verwendet, ich muß also auch diesen Begriff erläutern. Im Kontext dieses Dokumentes gilt:

Eine "Problem Domäne" ist ein Interessensbereich mit klarer Begrenzung in Bezug auf diese Interessen. Es kann im Prinzip alles sein, das durch Eigenschaften und Aktivitäten beschrieben werden kann, aber es muss eine selbständige (autonome) Einheit sein.

In diesem Dokument bezeichne ich ein spezifisches Geschäftsumfeld als "Problem Domäne". Solch ein Umfeld kann eine generische Domäne sein, wie etwa "Der Einzelhandel". Es kann aber auch eine sehr spezifische Domäne sein, wie etwa "Das Unternehmen XYZ". Dabei können beide Arten von Domänen wieder "Unterdomänen" haben. Die Unternehmensdomäne kann z.B. die Unterdomänen "Produktionsstätte UVW" aber auch "Verwaltung", "Produktion" und "Vertrieb" haben. Die "Einzelhandelsdomäne" könnte in "Einkauf" und "Verkauf" gegliedert sein.

Die Grenzen, die um Geschäftsdomänen gezogen sind, können sehr weit sein. Das bedeuted, dass viele Geschäftsdomänen mit denen wir zu tun haben werden, sehr komplex sein können, und zwar einfach wegen ihrer Größe.

Der Sinn und Zweck von Modellen

Modelle als die Beschreibung von etwas Realem (in unserem Kontext einer "Problem Domäne eines bestimmten Geschäftes") werden natürlich zu einem bestimmten Zweck erstellt. Hauptgrund der Erstellung ist der Wunsch nach einer gut strukturierten Beschreibung der Geschäftsdomäne die von allen Personen, die irgendwie mit dem Geschäftsfeld zu tun haben, leicht zu verstehen ist. Solch ein Modell kann dann auch dazu benützt werden, um den Geschäftsbereich in eine bestimmte Richtung hin weiterzuentwickeln und um in effektiver und wirtschaftlicher Weise die erforderliche Unterstützung für die Domäne daraus abzuleiten.

Um etwas konkreter zu sein: Ein Modell einer "Geschäftsfeld Problemdomäne", einmal erstellt, kann benutzt werden als

• ein Management-Instrument, um die Druchführung eines Geschäftes kontinuierlich zu verbessern oder um es an neue Herausforderungen anzupassen, indem wünschenswerte Sollzustände beschrieben werden. Es kann dem Verständnis der aufgetretenen oder auftretenden Veränderungen dienen, um das Geschäft aus einer "bestehenden" Situation herausführen. Der Vorteil für das Management ist, dass es mehrere potentielle Alternativen zur Umstellung des Geschäftsverhaltens und zur Anpassung von Organisationsformen in Bezug auf die "Vision" testen kann, ohne die bestehenden Organisationsformen und deren bestehende Prozeduren zu stören. Kostspielige real life Experimente können damit dramatisch reduziert werden.



• ein Unterweisungs-Instrument das es erlaubt:
• neuen Mitgliedern einer Organisation zu zeigen, wie diese Organisation arbeitet.
• den Mitgliedern einer Organisation zu erläutern, wie die Vision einer zukünftigen ("to be") Situation aussehen sollte und wie sich das Verhalten dieser Organisation ändern sollte.

Das Geschäftsmodell zeigt den "Profis", wie und unter welchen Bedingungen eine Organisation arbeitet. Wenn das Modell in geeigneter Weise gewartet und weiterentwickelt wird hat das den Vorteil, dass immer eine wohlstrukturierte und damit leicht verständliche Dokumentation vorhanden ist und dass die Ausbildung immer auf dem aktuellen Zustand basiert.


• ein Entwicklungswerkzeug um Systeme auszuwählen oder zu spezifizieren, die dazu dienen sollen, bestimmte Geschäftsbläufe der Problemdomäne zu unterstützen. Das hat den Vorteil, dass die Auswahl bzw. das Pflichtenheft auf den aktuellen Geschäftsbedürfnissen und einer (weitgehend) redundanzfreien, gut strukturierten und auf eine bestimmte Organistionsform optimierten Geschäftsfeldbeschreibung basiert.

Die folgende Liste zeigt, was durch die Benutzung eines Modelles tatsächlich erreicht werden kann:

• Definition der Grenzen einer Geschäftsfeld-Domäne.
• Festlegung der Schnittstellen zwischen benachbarten Problem Domänen.
• Optimierung der Organistionsstruktur eines Unternehmens.
• Erzielung eines Überblickes, wie bestimmte Geschäftsvorgänge momentan abgehandelt werden (im sogenannten "as is" Modell). Das Modell zeigt, welche Prozeduren durchlaufen werden und welche Daten manipuliert werden.
• Beschreibung einer idealen Geschäftsabwicklung (im sogenannten "to be" Modell). Das Modell zeigt, welche Prozeduren eingeführt bzw. abgeschafft werden sollten und welche Daten verwaltet werden sollten.
• Unterrichtung neuer Mitarbieter über die Art, wie ein Geschäft durch die Organisation abgehandelt wird.
• Überprüfung der Auswirkungen vorgesehener Änderungen auf den Geschäftsablauf durch Simulationsläufe.
• Festlegung von Bereichen, die durch Computerprogramme unterstützt werden sollten.
• Verwendung als Diskussionsgrundlage zwischen Geschäftsprofis und Anwendungsarchitekten um wünschenswerte Anwendungspakete umfangmäßig festzulegen.
• Evaluierung des Abdeckungsgrades des Funktionsangebotes von Standard-Anwendungspaketen, die für das Geschäftsfeld angeboten werden.
• ...

Modelle - Kategorisierung und Inhalt

Modelltypen

Modelle werden gewöhnlich nach ihrem Thema und ihrem Inhalt kategorisiert. Das ist es, was die folgende Liste versucht zu vermitteln, aber es gibt auch Gesichtspunkte, die sich an der "potentielle Anwendung" des Modelles orientieren. Die meisten der gelisteten Modelltypen können also zusätzlich sogenannte "as is" oder "to be" Modelle sein ("as is": Beschreibung eines aktuellen Ist-Zustandes; "to be": Beschreibung eines zukünftigen Soll-Zustandes).

Analyse Modell

Ein Modell, das essentielle Informationen enthält, die über eine Analyse einer bestehen Problem Domäne gewonnen wurden. Das Modell beschreibt zum Beispiel das Konzept einer Lösung eines oder mehrerer erforderlicher Anwendungsssysteme.

Geschäftsbereichsmodel

Ein Modell, das die Art und Weise zeigt, wie innerhalb eines Geschäftsbereiches (z.B. Vertrieb, Einzelhandel, Produktion, Verwaltung, ...) auf die Anforderungen der Kunden, Lieferante und sonstiger Partner reagiert wird. Das Modell gibt einen Einblick in ein Geschäftsverhalten im Allgemeinen und nicht wie es von einem bestimmten Unternehmen durchgeführt wird. Mögliche Inhalte eines solchen Modelles: "Use Cases", "Geschäftsobjekte", "Geschäftsprozesse" und "Geschäftsregeln".

Design Modell

Ein Modell, das die Beschreibung der Eigenschaften der Einzelkomponenten und deren Wechselwirkungen in einem Systemes enthält, das einem bestimmten Zweck dienen soll. Es beschreibt genauestens die Benützung der selektierten Elemente. Das Design Modell wird normalerweise aus dem Analysemodell abgeleitet.

Unternehmensmodell

Ein Geschäftsbereichsmodell das zeigt, wie ein bestimmtes Unternehmen ein bestimmtes Geschäft ausführt. Die Beziehungen zu Agenten ausserhalb des Geschäftsbereiches sind klar gekennzeichnet und sie sind Organisationen innerhalb des beschriebenen Unternehmens eindeutig zugeordnet. Ein Unternehmensmodell kann aus einem Industriemodell abgeleitet sein, das den Industriezweig beschreibt, dem das Unternehmen zuzuordnen ist.

Industriemodell

Ein Geschäftsbereichsmodell das eine vollständige Industriedomäne beschreibt. Es kann die Synthese mehrerer Geschäftsbereichsmodelle sein, die damit eine Industrie-Gesamtsicht ergibt.

Informationsmodell

Ein Modell, das nur die Daten eines Geschäftsbereiches enthält.

Problemdomänen Modell

Keine spezielle Modellform. Dies ist nur eine generische Bezeichnung für jede Art von Modellen.

System Modell

Ein Modell, das die Eigenschaften eines bestehenden oder zu entwickelnden Systems jeder Art beschreibt.

Workflow Modell

Ein Modell, das ausschließlich die Strukturierung der prozeduralen Aspekte und deren Automatisierung innerhalb eines Geschäftsbereiches behandelt. Es wird auch als Prozedurenmodell bezeichnet.

Anmerkung: Da ich in diesem Dokument im Allgemeinen über kommerzielle Anwendungsentwicklung für ein Unternehmen oder mehrere Unternehmen rede, meine ich "Geschäftsbereichsmodell" oder auch "Industriemodell" (als Modell, das mehrere Geschäftsbereiche abdeckt), wenn ich den Begriff "Modell" verwende.

Wichtige Modellinhalte

Was sollte ein Geschäftsbereichsmodell enthalten, um als Basis für eine kommerzielle Anwendungsentwicklung dienen zu können. Enthalten sollte es im Prinzip eine detaillierte Beschreibung

• der relevanten Parteien durch Beschreibung ihrer vorgesehenen "Rollen" und erforderlichen "Qualifikationen".
  Das kann eine Liste aller Typen von Parteien sein, die in der Geschäftsdomäne vorkommen. Es sollte aber zumindest eine Liste aller Berufsgruppen bzw. Berufsfunktionen sein, die zur Durchführung des Geschäftes erforderlich sind. Die Liste sollte die Berufsbezeichnung, das erforderliche Fachwissen, die notwendige Ausbildung bzw. Erfahrung und eine Aufzählung aller Aufgaben enthalten.
• Alle Aufgaben, die innerhalb der Problem Domäne anfallen (unabhängig davon, wer die Aufgabe ausführt - eine Person oder eine Maschine).
  Das kann eine Kombination von Textdokumenten und Diagrammen sein, die die elementaren Geschäftsaufgaben, die Hierarchie dieser Aufgaben (soweit es eine gibt), und deren Beziehungen zu Geschäftsobjekten und Arbeitsabbläufen beschreiben. Dabei beschreiben die Arbeitsabläufe die vorgeschlagene Reihenfolge von Aufgaben so, dass sie einer bestimmten Organisation angepasst sind.
• aller erforderlichen Geschäftsdaten der Problemdomäne.
  Das kann eine Kombination von Textdokumenten und Diagrammen sein, die alle Geschäftsobjekte inklusive ihrer internen Struktur beschreibt. Interne Struktur ist die Auflösung der Geschäftsobjekte in ihre Komponenten und deren Datenfelder mit ihren zulässigen Wertebereichen.

Modell Elemente sollten sein:

• Die Parteien (Organisationen) die innerhalb der Problemdomäne operieren.
• Die Parteien (Organisationen) die ausserhalb der Problemdomäne operieren, aber mit Parteien innerhalb der Problemdomäne zusammenarbeiten.
• Die Informationen (die Daten und deren Struktur) die in der Problemdomäne benützt werden.
• Die Geschäftsprozesse und Arbeitsabläufe, die für die Problemdomäne definiert sind.
• Die "Geschäftsgrundsätze" die innerhalb der Problemdomäne relevant sind.
• Die "externen Ereignisse", die innerhalb der Problemdomäne registriert werden.
• Die "Geschäftsergebnisse", die an aussenstehende Parteien kommuniziert werden.
• Die Hilfsmittel, die innerhalb der Problemdomäne verwendet werden.

Die Vollständigkeit der Modellelemente (auch als Modelleigenschaften bezeichnet) ist sehr wichtig für den Wert des Geschäftsbereichsmodelles. Von gleicher Wichtigkeit, und zwar für die Benutzbarkeit des Modelles ist es, wie diese Modellelemente aufgezeichnet und strukturiert sind. Das wird Thema eines besonderen Abschnittes dieses Dokumentes sein.

Ein Modell einer Problemdomäne kann niemals alle Aspekte des Originals in der realen Welt abdecken. Wichtig ist daher der Standpunkt des Betrachters (oder der Betrachter) der Geschäftsdomäne der realen Welt, die das Modell erstellen. Allgemein kann ich sagen, je vollständiger ein Modell in Bezug auf abgebildete Eigenschaften und je genauer die Beschreibung dieser Eigenschaften ist, je besser sind die Resultate, die aus dem Modell abgeleitet werden.
Das folgende kleine Beispiel illustriert, wie unterschiedlich der Inhalt eines Modelles sein kann, wenn die Problemdomäne mit den Augen von Betrachtern mit unterschiedlichen Interessen gesehen wird. Das Beispiel macht ebenfalls klar, dass ein Modell, das aus einer falschen Perspektive heraus erzeugt wurde, für einen vorgesehenen Zweck wertlos sein kann. Weiter verdeutlicht es, dass ein Modell nicht notwendigerweise alle Eigenschaften eines Originales abbilden muss, um nützlich zu sein.

Lasst uns eine "Straße" modellieren. Lasst uns dazu annnehmen, wir hätten zwei Beobachter. Der Erste sei ein Straßenbauingenieur, der Zweite ein Postzusteller.
Der Ingenieur wird sehr wahrscheinlich Eigenschaften wie "Straßenbreite", "Straßenlänge", "Belagsart", "Seitenstreifenbefestigung", usw. in sein Straßenmodell aufnehmen. Der Postzusteller dagegen wird interessiert sein an Eigenschaften wie "Straßenname", "Hausnummerierungssystem", "Art der Bebauung" (e.g. Industriegebäude, Wohngebäude,..), usw.
Beide Modelle sind unvollständig in Bezug auf die Eigenschaften der Straße in der realen Welt, aber beide Modelle können die essentiellen Eigenschaften in Bezug auf die modellierte Problemdomäne aufzeigen.