Diskussion:Geschäftsobjekt

Aus Löschdiskussion:

hmm... wird das so wie der Text zu Domain_Model? Überarbeiten Vielleicht wäre auch ein gemeinsamer Artikel zum Thema Objektmodell interessant. Aber so???--rhk 16:00, 19. Jan 2006 (CET)

ok, schicken Sie mir eine E-Mail. Da bin ich dabei. --Martin Wagenleiter 22:42, 3. Feb 2006 (CET)

außerdem wird nirgends erwähnt, worin der Unterschied zu einem normalen Objekt besteht, also die Verwaltungs-Methoden etc. Bleibe jedoch bei --> Überarbeiten --rhk 16:07, 19. Jan 2006 (CET)

Naja, ein Objekt ist ein Gegenstand. Das ist wirrer Computerkram... oder was meintest Du? ((ó)) Käffchen?!? 16:11, 19. Jan 2006 (CET)

also in der Informatik bedeutet ein Objekt_(Informatik) schon viel. Es gibt eben noch weitere Spezialisierungen zu dem Thema Objektorientierung. Das wird immer mehr. WP sollte sich nicht scheuen, auch (zumindest) Begriffserklärungen aus diesem Thema aufzunehmen. Aber in dieser Form ist die eigentliche Bedeutung eines Geschäftsobjekts nicht erklärt.--rhk 16:28, 19. Jan 2006 (CET)

Ja, stimmt: Das ist Computerkram, aber er ist nicht wirr. Fachgebiete wie die Programmiererei und die Geschäftswelt haben nun einmal ihre eigenen Begriffe. Und Geschäftsobjekte sind ein Teil des Brückenschlags, mit dem die beiden sich besser verständigen können. Deshalb habe ich den Artikel begonnen. Vielen Dank für die Hinweise. --Martin Wagenleiter 16:34, 19. Jan 2006 (CET)

Ach so Geschäftsobjekte sind z.b. Kunden und technische Objekte z.b. Datenbanken?? Dieser Artikel ist in der aktuellen Form zum großen Teil desinformativ. Wenn in 7 Tagen nichts draus geworden ist. -> löschen --FNORD 17:16, 19. Jan 2006 (CET).

Ich bitte um Hinweise, worin Sie die Desinformation sehen. --Martin Wagenleiter 22:42, 3. Feb 2006 (CET)

In der vorliegenden Version geht immer noch nicht hervor, worin der Unterschied zwischen Geschäftsobjekt und einer normalen Entität besteht. Auch ist ein Geschäftsobjekt nicht gleich einem Datenbankobjekt für einen Kunden oder einen Auftrag. Es verbindet viel mehr die Entität mit zusätzlichen Methoden (z.B. Berechnungen, Verwaltungsmethoden etc.) und stellt damit eine Komposition aus Domain Objekt, Entity und "Geschäftsmethoden" (Business Methods) dar. Zudem ist es öffentlich verfügbar. D.h. es existiert auf allen Schichten einer Client-Server-Architektur. Bitte korrigieren --rhk 10:13, 23. Jan 2006 (CET)

ok, baue ich noch ein. Danke. --Martin Wagenleiter 22:42, 3. Feb 2006 (CET)

Herkunft des Begriffs Geschäftsobjekt

Der Begriff Geschäftsobjekt ist kein Begriff aus der objektorientierten Softwareentwicklung, sondern stammt aus der Betriebswirtschaftslehre. Dort sind es die Gegenstände, an denen sich das Handeln in Prozessen vollzieht. Sprich: Die Gegenstände bzw. Dinge, die von den Aktionsträgern erstellt oder barbeitet werden. Ähnlich wird auch der Begriff des Aktionsobjekts bei Wild verwendet. Vgl.: Wild, Jürgen: Grundlagen und Probleme der betriebswirtschaftlichen Organisationslehre. Berlin 1966.

Unterschied Geschäftsobjekt - objektorientiertes Objekt

Hallo, bei der notwendigen Formulierung für eine Definition des Begriffs "Geschäftsobjekt" in Zusammenhang mit der objektorientierten Programmierung bin ich auf den Artikel gestoßen. Durch die vorgenommene Definition hebt sich ein Geschäftsobjekt von einem "normalen" objektorientiert gemeinten "Objekt" nur dadurch ab, dass es eine Teilmenge aller Objekte (z.B. auch technische Hilfsobjekte) bildet, nämlich die, die in einem (Geschäfts-)Prozess vorkommen. Die technische Anmerkung, dass ein Geschäftsobjekt aus "Daten" und "Verarbeitungslogik" besteht, ist die für ein Objekt: "Attribute" und "Methoden". Dabei bin ich ganz klar der Meinung, dass ein Geschäftsobjekt Entitäten-like auch ausschließlich "Daten" enthalten kann. Lediglich ist in einem größeren Zusammenhang der Umgang mit Geschäftsobjekten auf einer abstrakten Ebene definiert, was sie letztendlich von "normalen" Objekten, die etwas aus der Realität beschreiben, abhebt.

Man merkt vielleicht, ich komm mit dem Formulieren auch nicht besonders gut hinterher. Das ist alles auf ner ziemlich abstrakten Ebene. Jedoch denke ich nicht, dass die erzwungene Abgrenzung zu den Entitäten wie sie im Artikel beschrieben ist, korrekt ist, da dann die Abgrenzung zum "objektorientierten Objekt" fehlt. Ich hoffe, dass ist klar geworden.

"Geschäftsobjekte enthalten nicht nur Daten [...], sondern auch Verarbeitungslogik." Diese Aussage innerhalb des Artikels finde ich aus dem Blickwinkel Objektorientierung etwas verwirrend: Daten ordnet man doch Klassenobjekten zu, die Verarbeitungslogik (Methoden) hingegen der Klasse eines Klassenobjekts. --Abdull 22:38, 17. Feb. 2010 (CET)

überarbeiten

Der Artikel ist viel zu sehr auf Objektorientierte Programmierung ausgerichtet. Geschäftsobjekte werden auch in Systemspezifikationen gebraucht, ohne dass es später in OOP implementiert werden muss, sondern z.B. in relationellen Datenbanken. Siehe dazu Objektorientierte Analyse --Avron 16:29, 18. Jul. 2007 (CEST)

Überarbeitungsabsicht

Trotz vieler valider Anmerkungen (zu IT/DV lastig, Herkunft fehlt, Ziel der Verständlichkeit für Fachleute außerhalb der IT/DV verfehlt) hat sich an diesem Artikel in 1,5 Jahren inhaltlich wenig verändert. Ich plane ihn nun endlich zu überarbeiten. Sollten der ursprüngliche Autor oder ein Anderer sich mit derselben Absicht tragen, wäre eine Vorabstimmung sinnvoll, in diesem Fall bitte bis 13.01.2008 bei mir melden. --Nicola19 23:15, 28. Dez. 2007 (CET)

Ich möchte den Artikel jetzt umarbeiten: Geschäftsobjekte als semantische Brücke zwischen IT-Benutzern und IT-Erstellern

Als ich den Artikel vor zwei Jahren erstellt habe, hatte ich tatsächlich die Informatik-Brille auf. Ich hatte zwar schon das gemeint, was die Kritiker bemängelt haben, doch ich hatte es nicht klar genug beschrieben. Ich bedanke mich daher bei den Kritikern und möchte jetzt auf ihre Hinweise eingehen und den Artikel entsprechend verbessern.

Die Geschäftsobjekte sind zwar zu Anfang der neunziger Jahre im Zusammenhang mit der objektorientierten Software-Entwicklung entstanden, doch ihr Nutzen liegt darin, dass sie (a) (wenn sie gut = passend gewählt sind) die Denkwelt der IT-Benutzer repräsentieren UND (b) eine Struktur aufweisen, die 1:1 in technische Konstrukte der Software- oder Geschäftsprozessentwicklung umgesetzt werden kann (nicht muss). Diese Verankerung in beiden Welten ist die Ursache für ihre Eignung als Brücke.

Geschäftsobjekte bilden den Brückenschlag zwischen der Welt der IT-Benutzer und der IT-Ersteller, indem sie sowohl die Namen als auch die Begriffe (d.h. die mit den Namen gemeinten Inhalte) wiedergeben. Zusätzlich verfügen sie über Mechanismen zur Strukturbildung, die nach Meinung einiger Autoren (und nach meinen persönlichen Erfahrungen) mit den Strukturen der menschlichen Wahrnehmung übereinstimmen:

Peter Coad und Ed Yourdon haben ca. 1990 in ihrem Buch "Object-Oriented Analysis" dargelegt, wie die Konstrukte der Objektorientierung mit den Strukturen der menschlichen Wahrnehmung korrespondieren: Objekte und Klassen, Wissen und Verhalten, Generalisierung und Spezialisierung, Ganze und ihre Teile, Verknüpfungen, Themenbereiche. Dieses Buch war klein, klar und präzise. Es ist die beste und vollständigste Einführung in objektorientiertes Denken, das ich kenne. Deshalb habe ich es damals ins Deutsche übersetzt. Leider gibt es beide Ausgaben aber nur noch antiquarisch.

Ich selber (Martin Wagenleiter, geb. Rösch) habe mich seit 1992 ausschließlich mit dem Praxis-Einsatz von Objektorientierung befasst. Hierbei habe ich wahrgenommen, dass mein Verfahrenswissen ca. 1994 eine grundlegende Richtungsumkehr erfahren hat: Zu Beginn stand der erfindende IT-Ersteller im Fokus. Er schuf das Modell (und nach dem Modell dann die Software), mit dessen Hilfe eine Software die Aufgabenstellung im Sinne der IT-Benutzer möglichst optimal erfüllen sollte. Diese Sicht habe ich ca. 1994 aus meinem Erfahrungsschatz gestrichen. Jetzt standen die IT-Benutzer im Mittelpunkt. Genauer: ihre Weltsicht, und damit ihr Wissen. Für die IT-Ersteller bedeutete dies einen grundlegenden Wandel ihrer Rolle: Sie waren jetzt nicht mehr die Erschaffer von Modellen, sondern nur noch die getreuen Aufzeichner des Wissens der IT-Benutzer. Vom kreativen Schöpfer zum demütigen Treuhänder.

Diese Richtungsumkehr des Denkens führte insbesondere dazu, dass die Modellierungkriege (modelling wars) um das "richtige" Modell ihre Grundlage verloren. Ob ein Modell richtig ist oder nicht, wird heute anhand des dokumentierten Wissens der IT-Benutzer entschieden. Auf diese Weise kann es mehrere und unterschiedliche Modelle geben, die aber alle richtig sind, weil jedes von ihnen alle Anforderungen aus dem dokumentierten Wissen der IT-Benutzer erfüllt.

Deshalb möchte ich mich in meiner überarbeitung des Artikels auf die philosophische Schule des Konstruktivismus beziehen, die davon ausgeht, dass Menschen sich ihre Weltsicht selber konstruieren. Hierzu gehört dann auch die aus meiner Sicht kluge Aussage von Wittgenstein, dass Menschen erst dann verstehen, was ein Ding wirklich ist, wenn sie wissen, was sie damit machen können. Beschreibende Definitionen alleine schaffen das nicht.

Wenn Menschen eine Situation wahrnehmen, dann nehmen sie zuerst Objekte wahr. Und zwar nur solche Objekte, die im Zusammenhang mit ihren gegenwärtigen Absichten relevant sind. Dann prüfen sie die erkannten Objekte: Was haben sie gemeinsam? Was unterscheidet sie? Beide Fragen beantworten sie im Licht ihrer Absichten. Entsprechend fassen sie die Objekte zu Klassen zusammen. Bei Objekten ist wichtig, welches Fakten- und Verhaltenswissen ihnen zugeordnet wird. Für einen Kunden möchte man z.B. wissen, wie hoch sein Kreditlimit ist (Faktenwissen). Man möchte aber auch wissen, wie weit es bereits ausgeschöpft ist. Hierfür muss man die Beträge der noch offenen Aufträge des Kunden addieren (Verfahrenswissen). Ein Auftrag kann Positionen enthalten (ein Ganzes und seine Teile) und zu jeder Position kann eine Artikelbeschreibung gehören (Verknüpfung). Die eben dargestellten Beispiele beschreiben die Sicht von Menschen, die Aufträge annehmen (Themenbereich Auftragsannahme). Dieselbe Wirklichkeit kann aber zur selben Zeit von anderen Menschen anders wahrgenommen werden: Wer z.B. in der Logistik arbeitet und dafür sorgen muss, dass die bestellten Artikel schnell zum Kunden kommen, den interessiert das Kreditlimit nicht. Dafür muss er aber wissen, aus welchem Lager die Artikel abgerufen werden können. Für ihn sieht die Welt eben anders aus. Perception is reality. Und diese Perception wird dokumentiert, mit Hilfe von Beispielen und Geschäftsobjekten. --Martin Wagenleiter 00:00, 16. Feb. 2008 (CET)

Nur Mut: Geschäftsobjekte als semantische Brücke zwischen IT-Benutzern und IT-Erstellern

Hallo Martin Wagenleiter. Ich habe gerade Ihren Diskussionsbeitrag mit dem Vorschlag zur Umarbeitung gelesen (11 Jahre später) und möchte zustimmen. Das Geschäftsobjekt ist ein Analysewerkzeug, um das Wissen aus der Anschauung der IT-Benutzer abzufragen. Ich würde es umschreiben als einen/den Gegenstand der Anschauung, der im Zuge eines Geschäftsprozesses geschaffen wird oder eine Wertschöpfung erfährt. Zu Beginn der Analyse ist er nur eine Überschrift wie z. B. ein „Auto“ in einer Automobilfabrik oder ein "Versicherungsantrag" in einer Versicherung (der so lange geprüft und „veredelt“ wird, bis ein neues Geschäftsobjekt „Versicherungspolice“ entsteht). Diese Überschrift bildet den Ausgangspunkt der Analyse, was im Kontext des Geschäftsprozesses alles zu dem Geschäftsobjekt dazugehört. Ich stimme auch zu, dass in einem anderen Kontext die Zusammensetzung eines vermeintlich identischen Geschäftsobjekts ganz anders aussehen kann. Meine These ist daher: Das Geschäftsobjekt wird beschrieben durch eine lose Schüttung von Informationen (Attributen) im Kontext eines Geschäftsprozesses. Es besteht kein Zwang zur Normalisierung von Geschäftsobjekten. Vielmehr stelle ich es mir wie eine „Vorgangsakte“ vor (zumindest in der Verwaltung), an der gearbeitet (Wertschöpfung) wird. Der Nutzen der Bildung von Geschäftsobjekten besteht darin, dass sie sich an den Anwendern orientieren und mit der Abfrage der zugehörigen Attribute der Rohstoff für eine objektorientierte Analyse (Entity-Relationship-Modellierung) geliefert wird, die wiederum die Basis für die Datenmodellierung darstellen kann. Der Hinweis auf die Quelle zur Herkunft des Geschäftsobjekts aus der Betriebswirtschaftslehre (Wild, Jürgen) erscheint mir wertvoll. --Vantast (Diskussion) 12:35, 7. Jan. 2019 (CET)