Skip to main content

Part of the book series: Beiträge zur Wirtschaftsinformatik ((WIRTSCH.INFORM.,volume 20))

  • 37 Accesses

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.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 49.99
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 59.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. Vgl. [Sin91, S.457].

    Google Scholar 

  2. Vgl. [SA92, S.250].

    Google Scholar 

  3. Vgl. [Mü93, S.57].

    Google Scholar 

  4. So gehört z.B. eine bestimmte Kostenstelle zu den Fertigungskostenstellen und diese wiederum zu den Hauptkostenstellen.

    Google Scholar 

  5. Vgl. auch[MHH93, S. 86].

    Google Scholar 

  6. Vgl. [Cop92, S.202].

    Google Scholar 

  7. [CY91a].

    Google Scholar 

  8. Vgl. [CY91a, S.34].

    Google Scholar 

  9. Vgl. [CY91a, S.35].

    Google Scholar 

  10. Vgl. [CY91a, S. 53].

    Google Scholar 

  11. Vgl. [CY91a, S.53].

    Google Scholar 

  12. Vgl. z.B. [WWW90, S.38f] oder auch [Cop92, S.208].

    Google Scholar 

  13. Vgl. [Mey90, S.54].

    Google Scholar 

  14. Vgl. [Str92, S.440ff].

    Google Scholar 

  15. [Str92, S. 443].

    Google Scholar 

  16. In Anlehnung an den Begriff Bestandskonto, vgl. auch [MHH93, S. 78].

    Google Scholar 

  17. Siehe S. 15.

    Google Scholar 

  18. Siehe Abschnitt 3.5.

    Google Scholar 

  19. 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].

    Google Scholar 

  20. Vgl. [CY91a, S.179].

    Google Scholar 

  21. Vgl. [CY91a, S.79f].

    Google Scholar 

  22. Vgl. [Cop92, S.215].

    Google Scholar 

  23. Vgl. [Gib90b, S.95].

    Google Scholar 

  24. Vgl. [CY91a, S. 81].

    Google Scholar 

  25. 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].

    Google Scholar 

  26. Siehe Abschnitt 3.5.

    Google Scholar 

  27. Eine Matrix läßt sich als Tupel von Tupeln auffassen.

    Google Scholar 

  28. Vgl. [CY91a, S. 91].

    Google Scholar 

  29. Vgl. [CY91a, S.110].

    Google Scholar 

  30. Vgl. [CY91a, S. 119].

    Google Scholar 

  31. Vgl. [Cop92, S.216].

    Google Scholar 

  32. Vgl. [Gib90b, S.95].

    Google Scholar 

  33. Vgl. [CY91a, S.125].

    Google Scholar 

  34. Vgl. [CY91a, S.126ff].

    Google Scholar 

  35. Vgl. z.B. [Sch94c, S.652].

    Google Scholar 

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

    Google Scholar 

  37. Es handelt sich um eine Zeichenkette, nicht etwa um ein Objekt der Klasse GROESSE.

    Google Scholar 

  38. Vgl. auch Abbildung 4.3.

    Google Scholar 

  39. [Heu92, S.200].

    Google Scholar 

  40. Die Festlegung der Bezeichnung oder der Nummer als Identifizierungsattribut erfolgt im konkreten Fall durch Ausgestaltung des Konstruktors.

    Google Scholar 

  41. Vgl. auch die Ganzes-/Teile-Struktur.

    Google Scholar 

  42. Vgl. [CY91a, S.143].

    Google Scholar 

  43. Vgl. [CY91a, S.144ff].

    Google Scholar 

  44. Vgl. [CY91a, S.150].

    Google Scholar 

  45. Vgl. [Cop92, S.219].

    Google Scholar 

  46. [Gib90b, S.95].

    Google Scholar 

  47. Vgl. [Cop92, S.219].

    Google Scholar 

  48. Dagegen erzeugt die Methode FuegeEin der Klasse INDEXMENGE keine neuen Indexobjekte, denn diese existieren schon vorher.

    Google Scholar 

  49. Der Iterator der Klasse VEKTOR ist von dem der Klasse INDEXMENGE zu unterscheiden. Nähere Erläuterungen dazu erfolgen im nächsten Kapitel.

    Google Scholar 

Download references

Author information

Authors and Affiliations

Authors

Rights and permissions

Reprints 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

Publish with us

Policies and ethics