Advertisement

Konzeption einer wiederverwendungsfördernden Architektur

  • Karin Küffmann
Chapter
  • 38 Downloads
Part of the Programm Angewandte Informatik book series (PAI)

Zusammenfassung

Although (..) “architecture” has many definitions, it is often used in data processing to describe the set of fundamental assumptions which underlie a technology519.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Literatur

  1. 519.
    S. Jones, C. /Reusability in Programming/ S. 51.Google Scholar
  2. 520.
    Vgl. Jones, C. /Reusability in Programming/ S. 52.Google Scholar
  3. 521.
    Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/ S. 396.Google Scholar
  4. 522.
    Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/ S. 397.Google Scholar
  5. 523.
    Vgl. Gora, W. /Informatikarchitektur/ S. 20.Google Scholar
  6. 524.
    Vgl. Strunz, H. /Lehre von der Architektur/ S. 441.Google Scholar
  7. 525.
    Vgl. Frank, U. /Multiperspektivische Unternehmensmodellierung/Google Scholar
  8. 526.
    S. Strunz, H. /Lehre von der Architektur/ S. 443f.Google Scholar
  9. 527.
    Vgl. Mährländer, H.-J. /Strategische CASE-Planung/ S. 111.Google Scholar
  10. 528.
    Vgl. Hansen, W.-R. /Informationsmanagement/ S. 5ff.Google Scholar
  11. 529.
    Vgl. Sowa, J.; Zachman, J. /Extending and formalizing/ S. 592.Google Scholar
  12. 530.
    Vgl. Sowa, J.; Zachman, J. /Extending and formalizing/ S. 593.Google Scholar
  13. 531.
    S. Sowa, J.; Zachman, J. /Extending and formalizing/ S. 603.Google Scholar
  14. 532.
    S. Sowa, J.; Zachman, J. /Extending and formalizing/ S. 596. Sowa/Zachman schlagen eine Art von Marktmechanismus als klaren und eindeutigen Regelungsmechanismus für die Zuteilung von Menschen zu den zu erfüllenden Aufgaben vor. Damit würde die komplexe und schwer durchschaubare Organisationsstruktur transparenter und die Aufgaben effizienter erfüllt.Google Scholar
  15. 533.
    Vgl. Frank, U. /Multiperspektivische Unternehmensmodellierung/ S. 150.Google Scholar
  16. 534.
    Vgl. Sowa, J.; Zachman, J. /Extending and formalizing/ S. 602ff.Google Scholar
  17. 535.
    Die aufgeführten Teilsichten eines Systems werden erst im Laufe der Entwicklung beispielsweise durch die Verbindung von Ein- und Ausgabe von Funktionen mit Entitäten und Attributen hergestellt.Google Scholar
  18. 536.
    Vgl. Scheer, A.-W. /Architektur integrierter IS/ Vorwort.Google Scholar
  19. 537.
    Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/S. 396.Google Scholar
  20. 538.
    Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/S. 399.Google Scholar
  21. 539.
    Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/S. 400.Google Scholar
  22. 540.
    Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/S. 400.Google Scholar
  23. 541.
    Hier werden den Aufgaben Übertragung, Speicherung, Ein- und Ausgabe Techniken zugeordnet.Google Scholar
  24. 542.
    S. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/ S. 399.Google Scholar
  25. 543.
    Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/ S. 399. Vgl. Gora, WV Informatikarchitektur/ S. 19.Google Scholar
  26. 544.
    Es werden in den Anwendungssystemen die Kommunikationsschnittstellen realisiert, so daß eigentlich der Block Anwendungs-, Daten- und Kommunikationsarchitektur geschlossen dargestellt werden müssten.Google Scholar
  27. 545.
    Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 14.Google Scholar
  28. 546.
    S. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 17.Google Scholar
  29. 547.
    Die Begriffsbildung ist im Vergleich zu Zachman/Sowa ein wenig anders. Bei Zachman/Sowa werden Daten, Funktionen usw. als Elemente bezeichnet, in CIM-OSA werden sie als Sichten bezeichnet.Google Scholar
  30. 548.
    Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 46.Google Scholar
  31. 549.
    Vgl. Stotko, E. /CIM-OSA/ S. 10.Google Scholar
  32. 550.
    Vgl. ESPRIT Consortium AMICE (Ed). /Open System Architecture for CIM/ S. 46.Google Scholar
  33. 551.
    Vgl. ESPRIT Consortium AMICE (Ed). /Open System Architecture for CIM/ S. 50.Google Scholar
  34. 552.
    Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 48.Google Scholar
  35. 553.
    In der geplanten CIM-OSA-Referenzarchitektur sollen Referenzmodelle für jede industrielle Umgebung, für Einzelteilfertiger aller Branchen (Flugzeugbau, Maschinenhersteller, IT-Industrie usw), für alle Funktionen enthalten sein. CIM-OSA soll über einen Referenzkatalog für Unternehmens-, Design- und Implementierungsmodellierung sowie ein Systemdesign für eine endliche Anzahl an Building Blocks enthalten, die die rechnergestützte Modellierung unterstützen.Google Scholar
  36. 554.
    Vgl. ESPRIT Consortium AMICE (Ed). /Open System Architecture for CIM/ S. 47.Google Scholar
  37. 555.
    Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 93ff.Google Scholar
  38. 556.
    Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 39f.Google Scholar
  39. 557.
    Vgl. ESPRIT Consortium AMICE (ED) /OPS Architecture for CIM/ S. 193ff.Google Scholar
  40. 558.
    S. Wheeler, E. F.; Ghanek, A.G. /Introduction to Systems Application Architecture/ S. 250.Google Scholar
  41. 559.
    Eine Forderung der bestehenden Kunden geht in Richtung Integration von Anwendungen über Daten und Funktionen.Google Scholar
  42. 560.
    Vgl. wheeler, E. F.; Ghanek, A.G. /Introduction to Systems Application Architecture/ S. 250. Vgl. IBM /Writing Applications: A Design Guide/ S. 6.Google Scholar
  43. 561.
    Vgl. Wheeler, E. F.; Ghanek, A.G. /Introduction to Systems Application Architecture/ S. 250. Die den Betriebssystemen zugrundeliegende Struktur soll konsistent für alle Ziel-Plattformen sein.Google Scholar
  44. 562.
    Vgl. wheeler, E. F.; Ghanek, A.G. /Introduction to Systems Application Architecture/ S. 254.Google Scholar
  45. 563.
    S. Wheeler, E.; Ganek, A.. /Introduction to Systems Application Architecture/ S. 255.Google Scholar
  46. 564.
    Vgl. Berry, R. /Common User Access/ S. 281.Google Scholar
  47. 565.
    Vgl. Berry, R. /Common User Access/ S. 281.Google Scholar
  48. 566.
    Vgl. IBM /Writing Applications: A Design Guide/ S. 14. Vgl. Berry, R. /Common User Access/ S. 283f. Vgl. Uhlir, S. /Enabling the User Interface/ S. 306.Google Scholar
  49. 567.
    Vgl. Berry, R. /Common User Access/ S. 288.Google Scholar
  50. 568.
    Vgl. IBM /Writing Applications: A Design Guide/ S. 13.Google Scholar
  51. 569.
    Vgl. Ahuja, V. /Common Communications Support/ S. 264.Google Scholar
  52. 570.
    Vgl. Ahuja, V. /Common Communications Support/ S. 266.Google Scholar
  53. 571.
    Vgl. Ahuja, V. /Common Communications Support/ S. 270.Google Scholar
  54. 572.
    Vgl. Ahuja, V. /Common Communications Support/ S. 271.Google Scholar
  55. 573.
    Vgl. Wolford, D. /Application enabling in SAA/ S. 303. Vgl. IBM /Writing Applications: A Design Guide/ S. 18f.Google Scholar
  56. 574.
    Vgl. Wolford, D. /Application enabling in SAA/ S. 302f.Google Scholar
  57. 575.
    Vgl. IBM /Writing Applications: A Design Guide/ S. 18ff.Google Scholar
  58. 576.
    CSP: Cross System Product, wird in Verbindung mit ADW eingesetzt.Google Scholar
  59. 577.
    Vgl. Ahuja, V. /Common Communications Support/ S. 264.Google Scholar
  60. 578.
    Vgl. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 317ff.Google Scholar
  61. 579.
    Vgl. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 320.Google Scholar
  62. 580.
    S. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 320.Google Scholar
  63. 581.
    S. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 320.Google Scholar
  64. 582.
    Boehm stellt in seiner Untersuchung beispielsweise die hohe Anzahl an Housekeeping-Funktionen heraus, die mit der Einlagerung in die Basissysteme abnehmen.Google Scholar
  65. 583.
    S. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 320.Google Scholar
  66. 584.
    D.h. im Grunde liegt aufgrund der Vernetzung verschiedener Rechnertypen eine Notwendigkeit der Portierung von Programmen auf die anderen Umgebungen vor, solange die zur Verfügungstellung von Funktionen über die Netze für andere als die lokalen Rechner noch nicht realisiert ist. Diese Notwendigkeit der Portierung zeigt die Vorteile der wiederverwendungsorientierten Entwicklung i.S. einer einheitlichen Vorgehensweise und sinnvollen Modularisierung auf.Google Scholar
  67. 585.
    Vgl. Dunfee, W.; McGehe, J.; Rauf, R.; Shipp, K. /Designing SAA applications/ S. 328.Google Scholar
  68. 586.
    S. Dunfee, W.; McGehe, J.; Rauf, R.; Shipp, K./Designing SAA applications/ S. 329.Google Scholar
  69. 587.
    S. Dunfee, W.; McGehe, J.; Rauf, R.; Shipp, K./Designing SAA applications/ S. 344.Google Scholar
  70. 588.
    Vgl. Demers, R. /Distributed files for SAA/ S. 349.Google Scholar
  71. 589.
    Vgl. Demers, R. /Distributed files for SAA/ S. 350.Google Scholar
  72. 590.
    Vgl. Nagl, M. /Softwaretechnik/ Vgl. Denert, E. /Software-Engineering/ Vgl. Best. L. /Application Architecture/Google Scholar
  73. 591.
    Eine ähnliche Architektur, was das Angebot gleicher Dienste auf den Betriebssystemen anbelangt, entwickelt CA mit ihrer Architektur der 90er Jahre. Sie entwickeln für das Betriebssystem UNIX auf verschiedenen Endgeräten denselben Vorrat an Dienstprogrammen usw., so daß in hohem Maße Portabilität und Konnektivität entsteht. Die Grundlage für die Wiederverwendung ist die Vorgabe eies Anwendungsarchitekturrahmens wie es beispielsweise SAA zeigt. Eine Lösung auf herstellerunabhängigen Plattformen ist natürlich zu bevorzugen. Vgl. CA /CA90s/Google Scholar
  74. 592.
    Vgl. dazu auch Scheer, A.-W. /Architektur integrierter IS/ und Vgl. Scheer, A.-W./Modellierungbetriebswirtschaftlicher Informationssysteme/Google Scholar
  75. 593.
    Bei Scheer, der den gleichen Problembereich betrachtet, baut die Architektur ebenfalls auf den problem-relevanten Sichten der Daten, Vorgänge (mit Funktionen gleichgesetzt), Organisationen und Ressourcen auf. So stellt die vorgangsorientierte Sichtweise mit den genannten Sichten, eine Ausprägung des Problembereichs CIM dar.Google Scholar
  76. 594.
    Ähnliches wurde in CIM-OSA mit der Differenzierung verschiedener Particular Models vorgegeben.Google Scholar
  77. 595.
    Vgl. CIM-OSA.Google Scholar
  78. 596.
    Anhand der CIM-domänenbezogenen Architekturen wurde deutlich, daß die Sichten die für den Anwendungsbereich wichtigen Teilarchitekturen eines Informationssystems kennzeichnen. Sie stellen die problemrelevanten Sichten einer Domäne dar; d.h. sie müssen in jeder Domäne bestimmt werden.Google Scholar
  79. 597.
    Ähnliches bietet CIM-OSA; dort soll ein Domänenmodell entwickelt werden, das auf verschiedene Fertigungstypen und Unternehmensgrößen zugeschnitten wird. Den Unternehmen steht es frei, das passende allgemeine Modell für ihren Bedarf noch weiter zu verändern. Hier spielt bspw. das unternehmenseigene Vokabular und die vorherrschende Organisationsstruktur eine wichtige Rolle.Google Scholar
  80. 598.
    Eine andere Möglichkeit der Wiederverwendung bietet sich durch die Nutzung eines Funktionenmodelles. Anhand des Funktionenmodelles ist es möglich festzustellen, welche Funktionalitäten in Anwendungssystemen realisiert sind. Treten in der Entwicklung redundante Funktionen auf, so können sie wiederverwendet werden.Google Scholar
  81. 599.
    Gebräuchlich ist das State-Transition-Diagram; im Rahmen der objektorientierten Modellierung sind einige, auch methodisch eingebundene Verfahren zur Modellierung des zeitlichen Verlaufes entwickelt worden. Vgl. Shlaer, S.; Mellor, S. /An Object-Oriented Approach/Google Scholar
  82. 600.
    Damit können Module einfach eingehängt werden, so daß die Austauschbarkeit von Modulen mit gleichen Spezifikationen erleichtert wird. Wie in Kapitel 4 gezeigt, kann für die Realisierung einer anderen Anwendungsarchitektur mit diesem Konstruktionsprinzip die Austauschbarkeit der Module vereinfacht werden. Das domänenspezifische Design sollte in einer Designsprache — beispielsweise eine veränderte Form einer MIL — oder in graphischer eindeutiger Darstellung festgehalten werden. Damit Komponenten einsetzbar und austauschbar sind, ist auf die Entwurfskriterien Schnittstellenminimalität, Verkapselung, Information Hiding und Trennung zwischen Spezifikation von Modulen und ihrer Implementierung zu achten. Insbesondere die Trennung zwischen dem Systemdesign und der Modulspezifikation einerseits und der Implementierung andererseits birgt ein hohes Potential an Austauschbarkeit von Moduln. Damit kann ein hohes Maß an Flexibilität zum Modulaustausch und zur Erreichung einer hohen Allgemeinheit und somit Wiederverwendbarkeit des Designs realisiert werden.Google Scholar
  83. 601.
    Vgl. Bröhl, A.-R; Dröschel, W. (Hrsg.)/Das V-Modell/Google Scholar
  84. 602.
    Es ist in diesem Zusammenhang auf die hohen Wiederverwendungsraten aufgrund des standardisierten Vorgehens in der Flugzeugsteuerung bei NRL (Naval Research Lab) zu erinnern.Google Scholar
  85. 603.
    Vgl. Mertens, P.; Griese, J. /Integrierte Informationsverarbeitung/ S. 15.Google Scholar
  86. 604.
    Vgl. Heinrich, L.J. /Informationsmanagement/ S. 77f.Google Scholar
  87. 605.
    Vgl. Pagé, P. /strategien in der Software-Produktion/ S. 82. Vgl. Vetter, M. /Strategien in der Anwendungssoftware-Entwicklung/ S. 36f.Google Scholar
  88. 606.
    Vgl. Hansen, W.-R. /Informationsmanagement/ S. 5f. Der Informationsfluß in einem Unternehmen erfolgt entlang der zu optimierenden Wertschöpfungskette.Google Scholar
  89. 607.
    Vgl. Martiny, L. /Der Einsatz der DV/ S. 16ff.Google Scholar
  90. 608.
    Vgl. Martiny, L. /Der Einsatz der DV/ S. 21.Google Scholar
  91. 609.
    Bspw. wird in einem PPS-System durch Stücklisten und Arbeitspläne ein Modell der Vorgangsketten erfaßt, in dem die anzuführenden Arbeitsgänge, die einzusetzenden Produktionsbetriebsmittel und die notwendigen Materialien beschrieben werden. Diese werden in einem PPS-System als Umfeldbeschreibung abgelegt. Die Vorgänge des Informatonstransformationsprozesses, bei denen diese Daten als Umfeldzustände benutzt werden, sind bspw. Arbeitsplanung, Arbeitsvorbereitung.Google Scholar
  92. 610.
    S. Klein, J. /Vom Informationsmodell zum integrierten Informationssystem/ S. 10.Google Scholar
  93. 611.
    Damit wird die Informationssystemplanung an der Unternehmensstrategie orientiert. Aus der Unternehmensstrategie lassen sich die sie unterstützenden Aufgaben und entsprechend der Informationssystembedarf ableiten.Google Scholar
  94. 612.
    Wie die Beispiele aus der Datenmodellierung zeigen, ist eine Grobmodellierung ausreichend, urn die projektspezifischen konzeptuellen Datenmodelle den Entitäten auf Metaebene zuzuordnen.Google Scholar

Copyright information

© Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, Braunschweig/Wiesbaden 1994

Authors and Affiliations

  • Karin Küffmann

There are no affiliations available

Personalised recommendations