Softwarearchitektur - Metadaten, Systeme und Frameworks

Softwarearchitektur - Metadaten, Systeme und Frameworks 

Einleitung 

Die Systemarchitektur heutiger Online-Anwendungen, muss den Anforderungen nach  vernetzter Kommunikation und globaler Verfügbarkeit Rechnung tragen. Diese Anforderungen konnten durch große, monolithische Systeme nur schwer erfüllt werden, da sie propriertäre und abgeschlossene Systeme waren. Durch die Verbesserung der Netztechnologie in der 1980er Jahren sowie die gleichzeitige Verbesserung des Preis-Leistungsverhältnisses von  Prozessoren und Hardware, konnten neue verteilte  Systemarchitekturen entwickelt werden. Heutige Systemarchitekturen zeichnen sich dadurch aus, dass sie aus verschiedenen Komponenten bestehen und über Datenkommunikationsverbindungen miteinander Informationen austauschen. Die Verteilung der Systemkomponenten eines Informationssystems findet auf drei Ebenen statt, der Hardwareebene, der Betriebssystemebene und der Anwendungsebene.

Abb.  1- Systemebenen eines Informationssystems

Die Verteilung von Komponenten ist ein zentrales Entwurfs- und Implementierungsparadigma von Systemarchitekturen und ist zentraler Bestandteil von Technologieplattformen wie Java JEE und Microsoft .NET. Im Rahmen der technologischen Entwicklung der letzten Jahrzehnte entstanden neue Programmiersprachen und Technologien.

Die folgende Ausarbeitung soll die wichtigsten Bestandteile aktueller Systemarchitekturen und Technologien darstellen, dazu gehören:

• Systemarchitektur im Bereich Internet- und Mobile Computing Anwendungen
• Technologieplattformen und Frameworks
• Technologiekomponenten und Programmiersprachen

Modelle und Metadaten

Im Rahmen der Ausarbeitung werden in verschiedenen Bereichen auf Modelle referenziert wie unter anderem Prozessmodelle oder Datenmodelle. Nach (Stachowiak, 1973) können Modelle durch drei Hauptmerkmale definiert werden:

1. Das Abbildungsmerkmal steht dafür, dass Modelle natürliche oder künstliche Objekte darstellen, die selbst von Modellen abgeleitet sind.
2. Das Verkürzungsmerkmal steht für die Abstraktion des Originals, um nur auf die für einen Sachverhalt wichtigen Eigenschaften eines Objektes zu fokussieren.
3. Pragmatisches Merkmal steht dafür, dass Modelle nicht eins zu eins ihren Originalen zugeordnet werden können. So können Modelle nur einen Teilbereich des Originals abdecken, nur in bestimmten Zeitintervallen gültig sein sowie tatsächlichen oder gedachten Einschränkungen unterliegen[1].

In diesem Zusammenhang stehen auch die Begriffe Metamodell und Metadaten. Der Begriff Meta (griech.: „darüber hinaus“) steht für etwas Übergeordnetes. Metadaten beschreiben ein Objekt und sind damit „Daten über Daten“. Eine strukturierte Ablage von Metadaten auf elektronischen Medien erlaubt die elektronische Auswertung der Daten[2]. Ein Metamodell ist ein übergeordnetes Modell, welches die Regeln und die Grammatik für den Modellentwurf vorgibt. Wird ein Modell erstellt, eine Instanz des Metamodells gebildet, so baut dieses Modell auf den Regeln und Strukturen auf, die im Metamodell festgelegt sind[3].

Systeme und Systemkomponenten

Modelle werden unter anderem verwendet um Systeme zu beschreiben. Nach IEEE wird ein System allgemein wie folgt definiert:

“A system is a collection of components organized to accomplish a specific function or set of functions.”(IEEE Standard 610.12-1990)

Eine mehr Software orientierte Definition nach Rumbaugh lautet wie folgt:

“A system is a collection of connected units organized to accomplish a purpose. A system can be described by one or more models, possibly from different viewpoints. The complete model describes the whole system.”

Vogel beschreibt drei entscheidende Eigenschaften(Vogel, 2009 S. 59):

• Ein System ist eine Einheit, die aus wechselseitig interagierenden Teilen respektive Systembausteinen besteht….
• Ein System besitzt eine Systemgrenze die es von seiner Umwelt trennt
• Ein System existiert immer zur Erreichung eines Ziels

Dabei kann ein System aus Systembausteinen bestehen und selbst ein Systembaustein sein. Liegt eine hierarchische Ordnung von Systembausteinen vor, werden die Systembausteine auch Subsysteme genannt. Ein Systembaustein wird auch als Komponente bezeichnet, im Sinne eines in sich geschlossenen Bausteins einer Systemarchitektur[8].

Die IEEE Spezifikation (IEEE Standard 610.12-1990) definiert die Systemarchitektur als „organizational structure of a system or component”. Dabei ist eine Komponente ein abgeschlossener Teil eines Systems, der eine definierte Schnittstelle nach außen aufweist.  Der Architekturentwurf beschreibt den Aufbau und die Realisierung der Systemarchitektur auf Basis von Komponenten und Konnektoren. Nach IEEE (IEEE Standard 610.12-1990) sind  Konnektoren Verbindungen zwischen Komponenten.

Elemente der Softwarearchitektur sind:

• Komponenten
• definieren den Ort von Berechnungen, z.B. Filter, Datenbanken, Objekte, Server, Klienten usw.
• Beziehungen (Konnektoren)
• definieren die Interaktion der Komponenten, z.B. Funktionsaufruf, Pipe, Event usw.
• Eigenschaften
• definieren Vorgaben und Beschränkungen für Analyse und Design, z.B. Vorbedingungen, Qualitätsmerkmale usw.

Ziele der Systemarchitektur ist es:

·       Grundlegenden Entscheidungen für Entwurf (Design) und Implementierung des Systems festzulegen.

·       Die Kommunikation und Gesprächsablauf der Systembeteiligten (engl. Stakeholder) festzulegen.

·       Sie ist die Grundlage für die Erreichung funktionaler und qualitativer Merkmale des Systems.

Der Aufbau einer Systemarchitektur folgt oft wiederkehrenden Mustern[9]. Ein solches  Architekturmuster oder auch Architekturstil genannt, ist wiederverwendbar und auf andere Systeme übertragbar.

Softwaresystemarchitektur kann nach Abstraktionsgrad in verschiedene Architekturebenen eingeteilt werden:

Meta-Architektur

• hierzu zählt z.B. SOA als konzeptionelles Architekturmodell
• Makro-Architektur
• wird auf einem abstrakten Level definiert hierzu zählen die Architekturmuster wie z.B. die schichtenbasierte Softwarearchitektur (engl. Layer).
• Mikro-Architektur
• niedriger Abstraktionsgrad, z.B. Entwurfsmuster (Vorstufe für eine Implementierung)

Rahmenwerke (Frameworks)

Die IEEE Spezifikation (IEEE Standard 610.12-1990) definiert die Systemarchitektur als „organizational structure of a system or component”. Dabei ist eine Komponente ein abgeschlossener Teil eines Systems, der eine definierte Schnittstelle nach außen aufweist. Der Entwurf einer Softwaresystemarchitektur beschreibt den Vorgang und das Resultat des Softwaresystem Entwurfs (IEEE Standard 610.12-1990) und wird nach IEEE wie folgt definiert:

“The process of defining the architecture, components, interfaces, and other characteristics of a system or component and the result of that process”.(IEEE Standard 610.12-1990)

Im Rahmen des Grobentwurfs einer Softwareentwicklung muss ein Architekturentwurf des Softwaresystems erstellt werden (engl. Architectural Design). Ein Rahmenwerk (engl. Framework) ist ein Teil einer Softwaresystemarchitektur. Vogel definiert ein Framework als ein

„teilweise komplettes Software-System (oder Subsystem), das instanziiert werden soll. Somit definiert ein Framework eine Architektur für eine Familie von (Sub-) Systemen und stellt die elementaren Bausteine der Architektur zur Verfügung.“(Vogel, 2009 S. 160)

Aus Sichtweise der Softwarearchitektur sind Rahmenwerke ein Teil einer Systemarchitektur und basieren auf Klassenbibliotheken.

Nach (Balzert, 2000) können Klassenbibliotheken in zwei Arten unterschieden werden:

■         »Einfache« Klassenbibliotheken und

■         Rahmenwerke (frameworks).

Dabei üben »einfache« Klassenbibliotheken nur geringen Einfluss auf die Anwendungsarchitektur aus. Das wichtigste Ziel ist die Wiederverwendung von Quellcode. Demgegenüber stehen Klassenbibliotheken welche entscheidenden Einfluss auf die Softwarearchitektur haben, diese Bibliotheken stellen ein Rahmenwerk für die zu erstellende Software dar. Nach Gamma definiert sich ein Rahmenwerk wie folgt (Gamma, et al., 1995):

„Ein Rahmenwerk (framework) ist ein durch den Software-Entwickler anpassbares oder erweiterbares System kooperierender Klassen, die einen wiederverwendbaren Entwurf für einen bestimmten Anwendungsbereich implementieren. Es besteht aus konkreten und - insbesondere -aus abstrakten Klassen, die Schnittstellen definieren. Die abstrakten Klassen enthalten sowohl abstrakte als auch konkrete Operationen. Im Allgemeinen wird vom Anwender des Rahmenwerks erwartet, dass er Unterklassen definiert, um das Rahmenwerk zu verwenden und anzupassen. Diese selbstdefinierten Unterklassen empfangen Botschaften von den vordefinierten Rahmenwerk-Klassen nach dem Hollywood-Prinzip »Don't call us, we'U call you«“(Gamma, et al., 1995)

Unified Modelling Language

Die Unified Modelling Language ist allgemein anerkannte Notation zur Modellierung von Softwaresystemen[4] und aber auch anderen technischen Systemen (z.B. Embedded Real Time Systeme[5]). Die UML Notationen ist eine von der „Object Management Group“[6] (OMG) initiierter Standard und

„dient zur Modellierung, Dokumentation, Spezifizierung und Visualisierung komplexer Softwaresysteme, unabhängig von deren Fach- und Realisierungsgebiet. Sie liefert die Notationselemente gleichermaßen für die statischen und dynamischen Modelle von Analyse, Design und Architektur und unterstützt insbesondere objektorientierte Vorgehensweisen.“(Rupp, et al., 2007 S. 12)

Die in der Fallstudie verwendeten Modelle[7] sind u.a. Anwendungsfalldiagramme (engl.: use case diagram), Aktivitätsdiagramme (engl.: activity diagram), Klassendiagramme (engl.: class diagram), Komponentendiagramme (engl.: component diagram) und Verteilungsdiagramme (engl.: deployment diagram).

Autor: Friedhelm Feisel

---

[1] Siehe auch (Stachowiak, 1973).

[2] Ein Zitat von Tim Burners-Lee dem Erfinder des World Wide Web (WWW) beschreibt Metadaten wie folgt: „Metadaten sind maschinenlesbare Informationen über elektronische Ressourcen und andere Dinge“.

[3] Siehe auch Völter, M., & Stahl, T. (2006). Model-Driven Software Development : Technology, Engineering, Management . New York, NY : Wiley, J ., Seite 21.

[4] Siehe auch (Rupp, et al., 2007 S. 12 ff.).

[5] Siehe auch (Hruschka, et al., 2002).

[6] Die Object Management Group (OMG) ist ein Industriekonsortium mit über 800 Mitgliedern mit der Aufgabe herstellerneutrale Standards zu erstellen und zu pflegen.

[7] Für eine detaillierte Beschreibung und Definition der Modelle siehe (Object Management Group, Inc., 2010).

[8] Die Beschreibung einer Komponente geht zurück auf (Vogel, 2009 S. 161), Kapitel „6.2.3 Komponentenorientierung“.

[9] Siehe auch Christopher Alexander, Architekt und Systemtheoretiker (Alexander, 1977).

Literaturverzeichnis

Alexander, Christopher. 1977. A Pattern Language. New York : Oxford University Press, 1977.

Balzert, Helmut. 2000. Lehrbuch der Softwaretechnik : Basiskonzepte und Requirements-Engineering. Heidelberg : Spektrum, Akad. Verl., 2000. Bd. 2. Aufl.

Bundschuh, Manfred. 2000. Aufwandschätzung von IT-Projekten : [Zeit und Kosten von Anfang an im Griff haben ; Planungssicherheit durch zuverlässige Schätzung ; function point und andere Methoden] . Bonn : MITP, 2000. 3-8266-0534-9.

Deck, Klaus-Georg und Neuendorf, Herbert. Java-Grundkurs für Wirtschaftsinformatiker. s.l. : Friedr.Vieweg & Sohn Verlag. 978-3-528-05915-6.

Gamma, Erich, et al. 1995. Elemente wiederverwendbarer objektorientierter Software. s.l. : Addison Wesley in Pearson Education Deutschland GmbH, 1995.

Gibbs, R. Dennis. 2006. Project management with the IBM Rational Unified Process : lessons from the trenches. Upper Saddle River : Pearson Education, Inc./IBM Press, 2006. 0-321-33639-9.

Gunnerson, Eric. 2000. C# Die neue Sprache für Microsofts .NET-Plattform. Bonn : Galileo Press, 2000. 978-3898421072 .

Hruschka, Peter und Rupp, Chris. 2002. Agile Softwareentwicklung für embedded real time systems mit der UML. München; Wien : Hanser , 2002. 3-446-21997-8 .

IBM Corporation (DEV475). 2004. DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0:Student Manual, Volume 1:Version 2004.06.00. [Dokument] s.l. : International Business Machines Corporation (Rational University), 2004.

IEEE Computer Society;IEEE Std 1061-1998. 1998. IEEE Standard for a Software Quality Metrics Methodology - IEEE Std 1061-1998. http://standards.ieee.org/findstds/standard/1061-1998.html. [Online] 08. 12 1998. [Zitat vom: 21. 10 2011.] http://standards.ieee.org/findstds/standard/1061-1998.html. ISBN 0-7381-1059-6.

IEEE Standard 610.12-1990. IEEE Standard 610.12-1990.

Jacobson, Ivar, Booch, Grady und Rumbaugh, James. 1999. The unified software development process . Reading, Mass : Addison-Wesley, 1999. 0201571692.

Jendrock, Eric, et al. 2012. The Java EE 6 Tutorial. [Online] 01. 04 2012. [Zitat vom: 30. 04 2012.] http://docs.oracle.com/javaee/6/tutorial/doc/index.html.

Kruchten, Philippe. 1995. Architectural Blueprints—The "4+1" View Model of Software Architecture. IEEE Software. 1995, Bd. 12, 6.

Langer, Thorsten und Reiberg, Daniel. 2006. J2EE und JBoss. Verteilte Enterprise Applikationen auf Basis von J2EE, JBoss & Eclipse. Grundlagen und Profiwissen. s.l. : Hanser, 2006. 978-3446405080.

Münz, Stefan. 2007. SELFHTML: Version 8.1.2 vom 01.03.2007. http://de.selfhtml.org/. [Online] SELFHTML e.V., 01. 03 2007. [Zitat vom: 04. 05 2012.] http://de.selfhtml.org/intro/technologien/html.htm.

Object Management Group, Inc. 2010. Documents associated with UML Version 2.3. [Online] Object Management Group, Inc., 04. 05 2010. [Zitat vom: 07. 09 2011.] http://www.omg.org/spec/UML/.

Piwinger, Boris. 2001. Kommunikation im Internet. Kommunikationsmanagemen . Kommunikationsmanagement, Bentele, Günter / Piwinger, Manfred / Schönborn, Gregor (Hrsg), 2001, Bde. Luchterhand, 2001 ff. Loseblattwerk, 3. Ergänzungslieferung September 2002.

Rupp, Chris, Queins, Stefan und Zengler, Barbara. 2007. UML 2 glasklar : Praxiswissen für die UML-Modellierung. München; Wien : Hanser, 2007. 978-3-446-41118-0.

Schmidt, Douglas, et al. 2002. Pattern-orientierte Softwarearchitektur. Heidelberg : dpunkt.verlag GmbH, 2002. 3-89864-142-2.

Stachowiak, Herbert. 1973. Titel Allgemeine Modelltheorie. Wien, New York : s.n., 1973. 3-211-81106-0.

Vogel, Oliver. 2009. Software-Architektur : Grundlagen - Konzepte - Praxis. Heidelberg : Spektrum, Akad. Verl. , 2009. 978-3-8274-1933-0.