Geschäftsobjekt

Geschäftsobjekt (englisch business object) ist ein Begriff aus der objektorientierten Softwareentwicklung. Geschäftsobjekte dienen dazu, reale Größen und Abläufe in Informationssystemen zu modellieren. Sie enthalten neben Daten auch die Logik zu deren Verarbeitung (das unterscheidet sie von Entitäten).

Aufgabe

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.

Vorteile

Wenn man ein Informationssystem entlang der Strukturen der von ihm verwalteten Geschäftsobjekte aufbaut, ist es für Anwender und Softwareentwickler 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 Softwareentwickler 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.

Implementierung

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 Datenbanktabellen, 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.

Vorgehensweise

Softwareentwickler 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 Softwareentwickler 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.

Verallgemeinerung

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.

Abgrenzung zu Entitäten

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.

Beispiel

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 Computermonitore 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

Siehe auch

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

Literatur

• 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.