Zusammenfassung
Nachdem der Anwendungsbereich formal beschrieben wurde, wird im folgenden Schritt der objektorientierten Entwicklung die objektorientierte Analyse durchgeführt. Sie dient der Abstraktion und dem Verständnis der Diskurswelt. In der objektorientierten Analyse sind die fachlichen Anforderungen an das Anwendungssystem in objektorientierter Form zu definieren und darzustellen1. Dabei werden die für die Implementierung notwendigen Strukturen, insbesondere solche für die interne und externe Objektorganisation, noch nicht berücksichtigt. Sie sind erst Inhalt des objektorientierten Designs2.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Vgl. [Sin91, S.457].
Vgl. [SA92, S.250].
Vgl. [Mü93, S.57].
So gehört z.B. eine bestimmte Kostenstelle zu den Fertigungskostenstellen und diese wiederum zu den Hauptkostenstellen.
Vgl. auch[MHH93, S. 86].
Vgl. [Cop92, S.202].
[CY91a].
Vgl. [CY91a, S.34].
Vgl. [CY91a, S.35].
Vgl. [CY91a, S. 53].
Vgl. [CY91a, S.53].
Vgl. z.B. [WWW90, S.38f] oder auch [Cop92, S.208].
Vgl. [Mey90, S.54].
Vgl. [Str92, S.440ff].
[Str92, S. 443].
In Anlehnung an den Begriff Bestandskonto, vgl. auch [MHH93, S. 78].
Siehe S. 15.
Siehe Abschnitt 3.5.
Der hier verwandte Begriff „Aggregation“ darf nicht verwechselt werden mit dem Begriff Aggregation, der auch für die Ganzes-/Teile-Struktur verwandt wird, siehe z.B. [Ste93, S. 175].
Vgl. [CY91a, S.179].
Vgl. [CY91a, S.79f].
Vgl. [Cop92, S.215].
Vgl. [Gib90b, S.95].
Vgl. [CY91a, S. 81].
Nicht alle objektorientierten Programmiersprachen lassen die Mehrfachvererbung zu. In der Analyse sollte man sich diesbezüglich nicht von vornherein einschränken. Auch Coad/Yourdon sehen eine Mehrfachvererbung (multiple generalization) vor, siehe [CY9la, S. 88].
Siehe Abschnitt 3.5.
Eine Matrix läßt sich als Tupel von Tupeln auffassen.
Vgl. [CY91a, S. 91].
Vgl. [CY91a, S.110].
Vgl. [CY91a, S. 119].
Vgl. [Cop92, S.216].
Vgl. [Gib90b, S.95].
Vgl. [CY91a, S.125].
Vgl. [CY91a, S.126ff].
Vgl. z.B. [Sch94c, S.652].
Die Gruppenzugehörigkeit erleichtert die Bildung der Aggregation. Dadurch ist diese aber keineswegs vorgegeben. Die Kostenart kann beliebig in eine Indexmenge eines Objekts der Klasse AGG.INDEX eingefügt werden und auch Gegenstand verschiedener Aggregationen sein.
Es handelt sich um eine Zeichenkette, nicht etwa um ein Objekt der Klasse GROESSE.
Vgl. auch Abbildung 4.3.
[Heu92, S.200].
Die Festlegung der Bezeichnung oder der Nummer als Identifizierungsattribut erfolgt im konkreten Fall durch Ausgestaltung des Konstruktors.
Vgl. auch die Ganzes-/Teile-Struktur.
Vgl. [CY91a, S.143].
Vgl. [CY91a, S.144ff].
Vgl. [CY91a, S.150].
Vgl. [Cop92, S.219].
[Gib90b, S.95].
Vgl. [Cop92, S.219].
Dagegen erzeugt die Methode FuegeEin der Klasse INDEXMENGE keine neuen Indexobjekte, denn diese existieren schon vorher.
Der Iterator der Klasse VEKTOR ist von dem der Klasse INDEXMENGE zu unterscheiden. Nähere Erläuterungen dazu erfolgen im nächsten Kapitel.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 1997 Physica-Verlag Heidelberg
About this chapter
Cite this chapter
Schmidt, H. (1997). Objektorientierte Analyse des Anwendungssystems. In: Objektorientierte Entwicklung wiederverwendbarer Bausteine für betriebliche Anwendungssysteme. Beiträge zur Wirtschaftsinformatik, vol 20. Physica-Verlag HD. https://doi.org/10.1007/978-3-642-46996-1_4
Download citation
DOI: https://doi.org/10.1007/978-3-642-46996-1_4
Publisher Name: Physica-Verlag HD
Print ISBN: 978-3-7908-0976-3
Online ISBN: 978-3-642-46996-1
eBook Packages: Springer Book Archive