Zusammenfassung
“Although (..) “architecture” has many definitions, it is often used in data processing to describe the set of fundamental assumptions which underlie a technology”519.
This is a preview of subscription content, log in via an institution to check access.
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
S. Jones, C. /Reusability in Programming/ S. 51.
Vgl. Jones, C. /Reusability in Programming/ S. 52.
Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/ S. 396.
Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/ S. 397.
Vgl. Gora, W. /Informatikarchitektur/ S. 20.
Vgl. Strunz, H. /Lehre von der Architektur/ S. 441.
Vgl. Frank, U. /Multiperspektivische Unternehmensmodellierung/
S. Strunz, H. /Lehre von der Architektur/ S. 443f.
Vgl. Mährländer, H.-J. /Strategische CASE-Planung/ S. 111.
Vgl. Hansen, W.-R. /Informationsmanagement/ S. 5ff.
Vgl. Sowa, J.; Zachman, J. /Extending and formalizing/ S. 592.
Vgl. Sowa, J.; Zachman, J. /Extending and formalizing/ S. 593.
S. Sowa, J.; Zachman, J. /Extending and formalizing/ S. 603.
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.
Vgl. Frank, U. /Multiperspektivische Unternehmensmodellierung/ S. 150.
Vgl. Sowa, J.; Zachman, J. /Extending and formalizing/ S. 602ff.
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.
Vgl. Scheer, A.-W. /Architektur integrierter IS/ Vorwort.
Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/S. 396.
Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/S. 399.
Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/S. 400.
Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/S. 400.
Hier werden den Aufgaben Übertragung, Speicherung, Ein- und Ausgabe Techniken zugeordnet.
S. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/ S. 399.
Vgl. Krcmar, H. /Bedeutung und Ziele von Informationssystem-Architekturen/ S. 399. Vgl. Gora, WV Informatikarchitektur/ S. 19.
Es werden in den Anwendungssystemen die Kommunikationsschnittstellen realisiert, so daß eigentlich der Block Anwendungs-, Daten- und Kommunikationsarchitektur geschlossen dargestellt werden müssten.
Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 14.
S. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 17.
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.
Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 46.
Vgl. Stotko, E. /CIM-OSA/ S. 10.
Vgl. ESPRIT Consortium AMICE (Ed). /Open System Architecture for CIM/ S. 46.
Vgl. ESPRIT Consortium AMICE (Ed). /Open System Architecture for CIM/ S. 50.
Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 48.
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.
Vgl. ESPRIT Consortium AMICE (Ed). /Open System Architecture for CIM/ S. 47.
Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 93ff.
Vgl. ESPRIT Consortium AMICE (Ed.) /Open System Architecture for CIM/ S. 39f.
Vgl. ESPRIT Consortium AMICE (ED) /OPS Architecture for CIM/ S. 193ff.
S. Wheeler, E. F.; Ghanek, A.G. /Introduction to Systems Application Architecture/ S. 250.
Eine Forderung der bestehenden Kunden geht in Richtung Integration von Anwendungen über Daten und Funktionen.
Vgl. wheeler, E. F.; Ghanek, A.G. /Introduction to Systems Application Architecture/ S. 250. Vgl. IBM /Writing Applications: A Design Guide/ S. 6.
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.
Vgl. wheeler, E. F.; Ghanek, A.G. /Introduction to Systems Application Architecture/ S. 254.
S. Wheeler, E.; Ganek, A.. /Introduction to Systems Application Architecture/ S. 255.
Vgl. Berry, R. /Common User Access/ S. 281.
Vgl. Berry, R. /Common User Access/ S. 281.
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.
Vgl. Berry, R. /Common User Access/ S. 288.
Vgl. IBM /Writing Applications: A Design Guide/ S. 13.
Vgl. Ahuja, V. /Common Communications Support/ S. 264.
Vgl. Ahuja, V. /Common Communications Support/ S. 266.
Vgl. Ahuja, V. /Common Communications Support/ S. 270.
Vgl. Ahuja, V. /Common Communications Support/ S. 271.
Vgl. Wolford, D. /Application enabling in SAA/ S. 303. Vgl. IBM /Writing Applications: A Design Guide/ S. 18f.
Vgl. Wolford, D. /Application enabling in SAA/ S. 302f.
Vgl. IBM /Writing Applications: A Design Guide/ S. 18ff.
CSP: Cross System Product, wird in Verbindung mit ADW eingesetzt.
Vgl. Ahuja, V. /Common Communications Support/ S. 264.
Vgl. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 317ff.
Vgl. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 320.
S. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 320.
S. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 320.
Boehm stellt in seiner Untersuchung beispielsweise die hohe Anzahl an Housekeeping-Funktionen heraus, die mit der Einlagerung in die Basissysteme abnehmen.
S. Buchwald, L.; Davison, R.; Stevens, W. /Integration Applications with SAA/ S. 320.
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.
Vgl. Dunfee, W.; McGehe, J.; Rauf, R.; Shipp, K. /Designing SAA applications/ S. 328.
S. Dunfee, W.; McGehe, J.; Rauf, R.; Shipp, K./Designing SAA applications/ S. 329.
S. Dunfee, W.; McGehe, J.; Rauf, R.; Shipp, K./Designing SAA applications/ S. 344.
Vgl. Demers, R. /Distributed files for SAA/ S. 349.
Vgl. Demers, R. /Distributed files for SAA/ S. 350.
Vgl. Nagl, M. /Softwaretechnik/ Vgl. Denert, E. /Software-Engineering/ Vgl. Best. L. /Application Architecture/
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/
Vgl. dazu auch Scheer, A.-W. /Architektur integrierter IS/ und Vgl. Scheer, A.-W./Modellierungbetriebswirtschaftlicher Informationssysteme/
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.
Ähnliches wurde in CIM-OSA mit der Differenzierung verschiedener Particular Models vorgegeben.
Vgl. CIM-OSA.
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.
Ä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.
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.
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/
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.
Vgl. Bröhl, A.-R; Dröschel, W. (Hrsg.)/Das V-Modell/
Es ist in diesem Zusammenhang auf die hohen Wiederverwendungsraten aufgrund des standardisierten Vorgehens in der Flugzeugsteuerung bei NRL (Naval Research Lab) zu erinnern.
Vgl. Mertens, P.; Griese, J. /Integrierte Informationsverarbeitung/ S. 15.
Vgl. Heinrich, L.J. /Informationsmanagement/ S. 77f.
Vgl. Pagé, P. /strategien in der Software-Produktion/ S. 82. Vgl. Vetter, M. /Strategien in der Anwendungssoftware-Entwicklung/ S. 36f.
Vgl. Hansen, W.-R. /Informationsmanagement/ S. 5f. Der Informationsfluß in einem Unternehmen erfolgt entlang der zu optimierenden Wertschöpfungskette.
Vgl. Martiny, L. /Der Einsatz der DV/ S. 16ff.
Vgl. Martiny, L. /Der Einsatz der DV/ S. 21.
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.
S. Klein, J. /Vom Informationsmodell zum integrierten Informationssystem/ S. 10.
Damit wird die Informationssystemplanung an der Unternehmensstrategie orientiert. Aus der Unternehmensstrategie lassen sich die sie unterstützenden Aufgaben und entsprechend der Informationssystembedarf ableiten.
Wie die Beispiele aus der Datenmodellierung zeigen, ist eine Grobmodellierung ausreichend, urn die projektspezifischen konzeptuellen Datenmodelle den Entitäten auf Metaebene zuzuordnen.
Rights and permissions
Copyright information
© 1994 Friedr. Vieweg & Sohn Verlagsgesellschaft mbH, Braunschweig/Wiesbaden
About this chapter
Cite this chapter
Küffmann, K. (1994). Konzeption einer wiederverwendungsfördernden Architektur. In: Software-Wiederverwendung. Programm Angewandte Informatik. Vieweg+Teubner Verlag, Wiesbaden. https://doi.org/10.1007/978-3-322-86226-6_6
Download citation
DOI: https://doi.org/10.1007/978-3-322-86226-6_6
Publisher Name: Vieweg+Teubner Verlag, Wiesbaden
Print ISBN: 978-3-528-05457-1
Online ISBN: 978-3-322-86226-6
eBook Packages: Springer Book Archive