Geschäftsobjekt

Geschäftsobjekte bilden den Brückenschlag zwischen

1. den realen oder gedachten Objekten aus der Vorstellungswelt von Anwendern des Software-Systems und
2. den Objekten des Informationssystems.

Wenn man ein Informationssystem entlang der Strukturen der von ihm verwalteten Geschäftsobjekte aufbaut, ist es für Anwender und Software-Entwickler leichter zu verstehen. Auf Grund der hohen Übereinstimmung zwischen der empfundenen Wirklichkeit und der Struktur der Software nehmen Anwender ein solches System als „einfach“ wahr und Software-Entwickler finden sich bei seiner Entwicklung und Wartung schneller zurecht. Deshalb unterlaufen weniger Fehler, es gibt weniger Missverständnisse und durch die schnellere Entwicklung sinken auch die Kosten.

In objektorientierten Programmiersprachen werden Geschäftsobjekte direkt als Objektklassen der Programmiersprache implementiert. In älteren, nicht-objektorientierten Programmiersprachen wie z. B. COBOL oder C kann man Geschäftsobjekte nur indirekt, z. B. mit Hilfe des CORBA-Standards der OMG implementieren.

Im Gegensatz zu Geschäftsobjekten repräsentieren technische Objekte die anderen bzw. die restlichen Objekte von Informationssystemen. Technische Objekte sind z. B. die Fenster, Steuerelemente und Datenbank-Tabellen, die man zum Anzeigen, Bearbeiten und Speichern von Geschäftsobjekten braucht. Da die technischen Objekte nicht zur Vorstellungswelt der Anwender gehören, sind sie entsprechend auch nicht als Geschäftsobjekte anzusehen.

Software-Entwickler sollten sich zuerst darum kümmern, die Geschäftsobjekte ihrer Systeme richtig zu beschreiben. Dies tun sie, indem sie ein Objektmodell erstellen. Ein Objektmodell erfüllt dieselbe Aufgabe wie eine technische Zeichnung für z. B. eine Maschine oder ein Haus.

Erst, wenn das Objektmodell richtig ist, sollten Software-Entwickler das Software-System fertigstellen, indem sie es um die technischen Objekte ergänzen.

Ein Objektmodell ist richtig, wenn es alle Anforderungen erfüllt. Das Objektmodell erfüllt eine Anforderung, wenn es alle ihre Akzeptanzkriterien erfüllt. Und es erfüllt ein Akzeptanzkriterium, wenn die Messung, die vom Akzeptanzkriterium beschrieben wird, innerhalb des Objektmodells zum erwarteten Ergebnis führt.

Eine Verallgemeinerung des Begriffs „Geschäftsobjekt“ sind Domänen-Objekte. Das Wort „Domäne“ bezeichnet hierbei das Anwendungsgebiet des Software-Systems, z. B. die Steuerung einer Waschmaschine. In diesem Beispiel wäre es unpassend, den Motor, die Temperaturfühler und die anderen für die Software wichtigen Bestandteile der Waschmaschine als „Geschäftsobjekte“ zu bezeichnen.

Geschäftsobjekte sind eine ca. 1993 entstandene Weiterentwicklung von Entitäten. Sie unterscheiden sich von letzteren dadurch, dass sie nicht auf die Datenbank beschränkt sind, sondern auch Verarbeitungslogik (Methoden) enthalten. Häufig wird es als vorteilhaft gesehen, die gesamte Verarbeitungslogik von IT-Systemen den Geschäftsobjekten unterzuordnen.

Beispiele für Geschäftsobjekte sind die Kunden, Produkte und Bestellungen eines Auftragssystems. Wenn das Auftragssystem z. B. 1.000 Kunden, 2.000 Produkte und 3.000 Aufträge verwaltet, dann enthält es insgesamt 6.000 Geschäftsobjekte.

• Situation: Ein Auftrag mit 2 Artikelzeilen. In der 1. Artikelzeile stehen 5 Computer-Monitore und in der zweiten 10 Computer. Ein Monitor kostet 100 EUR und ein Computer 500 EUR. Diese Situation enthält 5 Geschäftsobjekte: Einen Auftrag sowie je 2 Auftragszeilen und Artikel.
• Aktion: Der Auftrag wird nach seinem Auftragswert gefragt.
• Erwartetes Ergebnis: 5.500 EUR.
• Erwarteter Ablauf:
  • Der Auftrag fragt die 1. Zeile: wie hoch ist Dein Zeilenpreis?
  • Die 1. Zeile fragt den Artikel „Monitor“: wie hoch ist Dein Preis?
  • Der Monitor antwortet: 100 EUR
  • Die 1. Zeile berechnet (Menge mal Preis) ihren Preis: 5 Monitore à 100 EUR = 500 EUR
  • Diesen Zeilenpreis (500 EUR) gibt sie an den Auftrag zurück.
  • Der Auftrag fragt die 2. Zeile, die ihren Zeilenpreis auf dieselbe Weise berechnet wie die 1. Zeile
  • Die 2. Zeile gibt ihren Zeilenpreis von (10 Computer à 500 EUR =) 5.000 EUR zurück
  • Der Auftrag addiert die beiden Zeilenpreise und gibt die Summe (500 plus 5.000 =) 5.500 EUR zurück

• Domain-driven Design - Vorgehen zu Modellierung der Geschäftsobjekte im Objektorientierten Umfeld

• Christoph Lordieck: Praxishandbuch BOPF - das Business Object Processing Framework im neuen SAP S/4HANA-Programmiermodell. Espresso Tutorials, Gleichen 2019, ISBN 978-3-96012-788-8.