e.academy
.tutorials
.kiosk
.magazine
.service
Anmelden|Abmelden
.videos
Entwickler Magazin
PHP Magazin
Java Magazin
Business Technology Magazin
JavaScript Kompendium
Cloud Compendium
Kontakt & Leserservice
Bücher & E-Books
Kontakt & Service entwickler.press
.slides
Start Online Development
Teil 5: Anwendungsarchitektur festlegen und umsetzen
Einführung in die Programmierung: Struktur sorgt für Qualität
Dr. Veikko Krypczyk, Olena Bochkor 5 Jahren online 1 Kommentar
Umfangreiche Softwaresysteme sind komplex. Sie zu gestalten und deren Erweiterungsfähigkeit auch noch nach Jahren sicherzustellen, ist eine besondere Herausforderung. Es geht um Softwarearchitektur – ein Thema, bei dem es wichtig ist, sich bereits in der frühen Lernphase der Programmentwicklung damit zu beschäftigen.
© Shutterstock / nirutti
Einführung in die Programmierung: Daten, Daten, Daten
Die Architektur eines Softwaresystems ist gewissermaßen dessen Grobstruktur. Selbst wenn man sich keine expliziten Gedanken über die Gestaltung der Architektur macht, wird automatisch bei der Programmentwicklung – also in der Phase der eigentlichen Implementierung – eine Architektur erzeugt. Die Frage ist nur: In welcher Qualität? Software ist, von Minianwendungen abgesehen, meist komplex und besteht aus einer Vielzahl von Einzelkomponenten. Die Zerlegung in Komponenten ist dabei bereits ein Zugeständnis, dass man das Gesamtsystem nicht beherrschen kann. Immer dann, wenn der Umfang bzw. die Komplexität zu groß werden, behilft man sich mit einer Aufspaltung in einzelne Bestandteile. Dabei treten zwangsläufig folgende Fragen auf:
Nach welchem Prinzip soll die Aufteilung erfolgen?
Wie sind die Schnittstellen definiert und auf welche Weise erfolgt die Zusammenarbeit zwischen den Komponenten?
Die Beantwortung und letztendlich die Festlegung dieser beiden Fragen führt zur Architektur des Softwaresystems. Die Architektur wird also nach außen nicht sichtbar und richtet sich dementsprechend nur an die Entwickler. Der Kunde/Endabnehmer kommt daher nicht explizit damit in Berührung. Implizit wirkt sich jedoch der architektonische Entwurf auf die Qualität aus. Unmittelbar werden davon die Wartbarkeit und die Erweiterbarkeit des Softwaresystems beeinflusst. Aus diesen Feststellungen ist daher bereits zu schlussfolgern:
Die Architektur einer Anwendung ist explizit zu gestalten. Sie darf nicht der zufälligen Entwicklung überlassen werden.
Sie ist für alle Softwaresysteme immanent, d. h. außer bei „minimalistischen“ Programmen mit lediglich nur einem linearen Ablauf hat sie Einfluss auf die Qualität.
Diese Gründe sprechen dafür, sich frühzeitig mit dem Thema zu beschäftigen, deshalb finden Sie es im Rahmen dieses Einführungskurses (Kasten: „Artikelübersicht“).
Einführung in die Programmierung – die Serie
Teil 1: Einführung: Programmentwicklung, Sprachen, Entwicklungsumgebung
Teil 2: Basics: Variablen, Datentypen, Ablaufstrukturen, Algorithmen
Teil 3: Objektorientierung: Klassen, Eigenschaften, Methoden, Ereignisse, Vererbung
Teil 4: User Interface: Design aus technischer Perspektive
Teil 5: Architektur: Anwendungsschichten und Kopplung, Model-View-Controller-Muster
Teil 6: Daten: Datenbanktheorie und Datenmodellierung
Die Bedeutung des Themas kann man auch daran erkennen, dass neben Entwicklern oft auch so genannte Softwarearchitekten beschäftigt sind. Ihre Aufgabe besteht in der Festlegung der Softwarearchitektur; außerdem geben sie dem gesamten Entwicklungsprozess den notwendigen Rahmen. Daran müssen sich alle beteiligten Entwickler peinlich genau halten.
Da sich Softwaresysteme – trotz unterschiedlicher Zielrichtung, Systemtechnik und Einsatzbedingungen – in einer gewissen Weise in bestimmte Kategorien einteilen lassen, hat die Informatik zum Thema Architektur eine Menge an Empfehlungen, Standardisierungsvorschlägen und Best Practices entwickelt.
Wenn man beginnt, sich mit diesem Thema zu beschäftigen, ist es daher einerseits ratsam, eine Istanalyse der Programmieraufgabe bezüglich der Zugehörigkeit zu einer Klasse durchzuführen, und andererseits ein möglichst breites Set von Musterarchitekturen parat zu haben. Solche Musterarchitekturen werden auch als Entwurfsmuster bezeichnet und gelten allgemein, d. h. sie sind nicht auf eine bestimmte Zielumgebung, Anwendungsklasse und/oder Programmiersprache festgelegt.
Klären wir aber zunächst die grundsätzlichen Zielrichtungen zur Anwendungsarchitektur. In einem zweiten Schritt stellen wir wichtige Prinzipien der Architektur vor. Um gleich etwas Praxisbezug in unsere Ausführungen zu bringen, wird am Beispiel einer datengetriebenen Desktopanwendung konkret über das MVVM-Pattern (Model View ViewModel) diskutiert. Es ist eine spezielle Variante zur Trennung der unterschiedlichen Aufgaben für ein Softwaresystem, das Daten verarbeitet. Die Datenverarbeitung ist bekanntermaßen das zentrale Thema von Businessapplikationen. Ebenso geben wir kurze Einblicke in die serviceorientierte Architektur (SOA) und die Architektur integrierter Informationssysteme (ARIS).
Ziele und Bestimmungsgründe für eine Architektur
Wie bereits ausgeführt, ist der Architekturentwurf die Grobstruktur eines Softwaresystems. Dabei geht es um die Beantwortung folgender Fragen [1]:
Wie ist das Gesamtsystem organisiert?
Und wie kann die Gesamtstruktur entworfen werden?
Es handelt sich um einen kreativen Prozess, dessen Aktivitäten von der Art des zu entwickelnden Systems, den Erfahrungen der Systemarchitekten und natürlich von den spezifischen Systemanforderungen abhängig sind. Auch einzigartige Softwaresysteme weisen oftmals ähnliche Architekturen auf, die in Architekturmuster zusammengefasst sind.
Die große Herausforderung besteht darin, die allgemeingültigen Muster in der eigenen Problemstellung/im eigenen Softwaresystem wiederzuerkennen. Dazu ist es auch notwendig, sich Änderungen gegenüber der Istsituation vorstellen zu können, um einen Wiedererkennungseffekt zu erreichen. Um Muster zu erkennen, kann man sich u. a. folgende Leitfragen stellen:
Was ist der grundlegende Ansatz zur Strukturierung?
Wie werden die Komponenten in Teilkomponenten zerlegt?
Welche Architekturmuster sehen dem vorliegenden System ähnlich?
Wie soll die Systemarchitektur dokumentiert werden?
Wie soll der Entwurf bewertet werden?
Wird das System auf mehrere Prozessoren aufgeteilt?
Grundsätzlich kann man ein System aus verschiedenen Sichtweisen betrachten:
Logische Sicht: Diese Perspektive zeigt Hauptabstraktionsebenen im System als Objekte oder Objektklassen.
Prozesssicht: Diese Sichtweise zeigt, wie sich das System aus interaktiven Prozessen zusammensetzt. Die Sichtweise ist nur zur Laufzeit gültig.
Entwicklungssicht: Es wird die Aufteilung der Software in Komponenten dargestellt.
Physische Sicht: Die physische Sicht stellt dar, wie die Softwarekomponenten über die Systemprozessoren verteilt sind.
Konzeptuelle Sicht: Darunter ist eine abstrakte Sicht auf ein System zu verstehen, die als Basis für die Zerlegung übergeordneter Anforderungen dienen kann.
Architekturprinzipien
Eine gute und durchdachte Architektur sollte bestimmten Handlungsmustern (Architekturprinzipien) folgen, die abstrakt und allgemeingültig sind. Dazu gehören Abstraktion, Strukturierung, Bindung und Kopplung, Modularisierung, Geheimnisprinzip, konzeptionelle Integrität und die Trennung von Zuständigkeiten.
Grundsätzlich gilt, dass die konzeptionelle Integrität einzuhalten ist, d. h. die angewendeten Architekturentscheidungen sollen über das gesamte System beibehalten werden. So sollten die Schnittstellen zwischen den Komponenten alle einheitlich aufgebaut sein. Unter dem Prinzip „Trennung von Zuständigkeiten“ versteht man, dass jede Komponente der Architektur nur für eine Aufgabe oder einen Aufgabenkomplex verantwortlich ist. Da die Zuständigkeiten klar voneinander abgegrenzt sind, ergibt sich daraus eine modulare Architektur. Es ist jedoch zu berücksichtigen, dass eine zu starke Trennung zur Fragmentierung führen kann.
Übersichtlichkeit, Verdichtung und Abstraktion sind ausgewogen zu gestalten (Prinzip der Ökonomie). Dabei vermeidet Übersichtlichkeit ein Durcheinander. Unter Verdichtung wird Geradlinigkeit und Klarheit im Entwurf verstanden, was das Verständnis der Architektur erleichtert. Die Abstraktion sorgt dafür, dass unnötige Details ausgeblendet werden. Das Prinzip der Symmetrie verlangt einen konsistenten, geordneten und ausgewogenen Entwurf. Das Prinzip der Sichtbarkeit ist dann eingehalten, wenn die Artefakte deutlich und ausdrucksstark beschrieben sind. Ein Beispiel: Wenn die Schnittstellen nicht ausdrucksstark beschrieben sind und ihre Aufteilung unklar ist bzw. die Dokumentation fehlt, folgt eine schlechte Modifizierbarkeit und Wartbarkeit des Systems [2].
Entwurfsmuster
Ein Entwurfsmuster präsentiert eine bewährte Lösung für ein allgemeines Entwurfsproblem. Es beschreibt das Zusammenwirken der einzelnen Elemente, zum Beispiel auf Ebene der Klassen. Es bietet folgende Vorteile:
abgeleitet aus der Praxis, daher erprobt und nachvollziehbar
bietet den Rückgriff auf die Erfahrungen anderer Entwickler
Förderung des Konzeptes der Wiederverwendung
verbesserte und vereinfachte Dokumentation der Anwendungsentwicklung, sofern die eingesetzten Muster kenntlich gemacht werden
bietet eine gute Kommunikationsbasis zwischen den Entwicklern
Es gibt zahlreiche Entwurfsmuster. Eine Unterscheidung ist nach dem Aufgabentyp möglich; zu nennen sind dabei Erzeugungs-, Struktur- und Verhaltensmuster. Auch ist eine Differenzierung danach möglich, ob primär Klassen oder Objekte betrachtet werden. Es würde den Rahmen dieses Artikels sprengen, eine Vielzahl von Entwurfsmuster vorzustellen. Eine Auswahl zeigt Tabelle 1 am Ende des Artikels. Ein Entwurfsmuster setzt sich aus mehreren Bestandteilen zusammen. Dazu gehören der Name/die Beschreibung, die Verwendung und die Vor- und Nachteile.
Abb. 1: Model-View-Controller-Muster [1]
Abb. 2: Das Schichten-Architektur-Muster [1]
Abb. 3: Ein Repository-Muster am Beispiel einer Entwicklungsumgebung [1]
Abb. 4: Ein Client-Server-Muster am Beispiel einer Filmbibliothek [1]
Abb. 5: Pipes-and-Filter-Muster am Beispiel eines Geschäftsprozesses [1]
Ganz konkret: SOA und ARIS
Eine ganz konkrete Ausgestaltung eines allgemeingültigen Architekturmusters ist die serviceorientierte Architektur (SOA). SOA versucht es dem Nutzer zu ermöglichen, dass durch das Zusammenfassen von großen „Funktionsbrocken“ Ad-hoc-Anwendungen fast vollständig aus vorhandenen Services erstellt werden können. Dahinter steht die Idee, sinnvoll zusammengehörende Anwendungsfunktionalitäten zu einer Einheit zu bündeln und sie als Dienstleistungen (SOA-Services) zur Verfügung zu stellen. Komplexe Anwendungssysteme entstehen dann durch das Kombinieren mehrerer Services. Die vorhandenen Services können wiederverwendet und es können so ggf. Entwicklungskosten gespart werden. Die Einsparungen treten jedoch nur dann auf, wenn die grundlegenden Services bereits existieren [1].
Ein weiterer Ansatz zur Festlegung der Architektur für betriebliche Anwendungssysteme ist die Architektur integrierter Informationssysteme (ARIS) [3]. Dieses Konzept zielt darauf ab, dass eine Aufteilung eines betrieblichen Informationssystems in Beschreibungssichten und Ebenen (Abb. 6) erfolgt. Es lassen sich fünf Beschreibungssichten identifizieren:
Organisationssicht: Beschreibung der Organisationseinheiten und ihrer Beziehungen
Datensicht: Beschreibung der Informationsobjekte und deren Attribute, sowie der Beziehungen zwischen den Informationsobjekten
Steuerungssicht: Verbindung der zu Reduzierung der Komplexität von Geschäftsprozessen separat betrachteten anderen Sichten, um die Zusammenhänge und das dynamische Verhalten zu veranschaulichen
Funktionssicht: Beschreibung der Funktionen und zwischen ihnen bestehender statischer Beziehungen
Leistungssicht: Beschreibung aller materiellen und immateriellen Input- und Outputleistungen einschließlich der GeldflüsseJede Beschreibungssicht wird in drei Ebenen untergliedert:
Fachkonzept: Mittels Beschreibungsmodellen werden Geschäftsprozesse strukturiert dargestellt. Ausgangspunkt ist die Identifizierung und Definition der fachlich-betriebswirtschaftlichen Anforderungen.
DV-Konzept: Das Fachkonzept wird anschließend in ein IT-Architekturmodell überführt.
Implementierung: Beschreibt die Umsetzung in ein Informationssystem.
Abb. 6: ARIS-Haus nach Scheer [4]
Nach diesem großen Ausflug in die Architektur von Anwendungssystemen (Theorie) kommen wir nun ganz konkret auf die Umsetzung von Architekturentscheidungen in der Praxis zurück. Datenbasierte Anwendungen – zum Beispiel klassische Businessanwendungen – verfügen alle über ähnliche funktionelle Aufgaben; damit kann ein einheitliches Strukturmuster angewendet werden. In der Praxis haben sich dazu Varianten des Model-View-Controller-Musters (MVC-Muster) etabliert. Von Varianten spricht man deshalb, weil Anpassungen an das jeweilige Framework und/oder die jeweilige Programmiersprache zu spezifischen Systemausprägungen geführt haben.
Wir haben in unserem Kurs bisher auf das .NET Framework und C# als Programmiersprache gesetzt. Das soll auch so beibehalten werden. Für Windows Presentation Foundation (WPF) und .NET hat sich das MVVM-Muster etabliert, das auf dem MVC-Muster basiert. Im Folgenden wird es anhand eines kleinen Beispiels vorgestellt [4]. Ziel dieses Musters ist es, eine Trennung zwischen Benutzeroberfläche (UI), der steuernden Logik und der Schicht zur Datenhaltung zu erreichen.
WPF-Anwendungen basieren bezüglich des UI auf XAML-Code (siehe auch die Ausführungen im letzten Teil unserer Artikelserie). XAML ist rein deklarativ; komplexere Operationen müssen in die so genannten Code-Behind-Dateien ausgelagert werden. Zwischen den genannten Schichten soll eine Abhängigkeit weitgehend vermieden werden. Diese Trennung hat den Vorteil, dass man beispielsweise das UI einfach austauschen kann. Gemäß dem MVVM-Muster enthält es folgende Bestandteile:
Model: Es repräsentiert die Daten der Anwendung. Sie können aus einer Datenbank oder aus jeder beliebigen anderen Quelle stammen. Üblicherweise werden sie in Form von Klassen repräsentiert. Die Aufgabe des Models ist es nicht, eine Repräsentation der Daten zu gewährleisten.
View: Hier wird die Sicht für den Anwender beschrieben. Sie enthält dabei auch keine Programmlogik. Sie ist auch für die Entgegennahme von Benutzerdaten zuständig. In verschiedenen Darstellungen des Entwurfsmusters ist man sich nicht ganz einig, ob beispielsweise Methoden zur Validierung in der View oder (im nachfolgend beschriebenen) ViewModel hinterlegt werden. Es bleibt beim Grundsatz, dass die View möglichst keine Logik zur Datenverarbeitung enthält. Im Übrigen ist es möglich, dass eine Anwendung über mehrere Views (Anzeigen) verfügt.
ViewModel: Zwischen der Datenschicht (Model) und der View ist das ViewModel Es ist das Bindeglied zwischen beiden Schichten. Die View übermittelt die Daten an das ViewModel, das wiederum mit der Datenschicht (Model) interagiert. Das ViewModel registriert, wenn sich die Daten ändern und leitet sie an die registrierten Views weiter. Ebenso funktioniert dies auch in die andere Richtung.
Ein wirklich einfaches Beispiel zum Nachvollziehen einer kleinen Desktopapplikation in WPF und C# findet man zum Download hier.
Tabelle 1: Wichtige Architekturmuster, Zusammenstellung nach [1]
Fazit und Ausblick
Obwohl genug Inhalte zu verdauen sind, gibt es zu diesem Teil der Artikelserie keine Hausaufgabe. Sie haben einen freien Nachmittag! Nutzen Sie die Zeit, um vielleicht über die Architektur Ihrer bisher implementierten Anwendungen nachzudenken. Gibt es Verbesserungsoptionen, kann man die Klassen und Funktionen vielleicht geschickter und übersichtlicher aufteilen? Gerade das zuletzt vorgestellte MVVM-Muster ist sehr gut wiederzuverwenden. Richtig, es scheint auf den ersten Blick die Anwendung größer zu machen. Aber die Übersicht wird besser – und damit auch die Wartbarkeit. In den kommenden Teilen des Kurses setzen wir nahtlos an den hier vorgenommenen Ausführungen an. Eine wichtige Schicht in Softwaresystemen ist für die Datenhaltung zuständig. Wie sie zu modellieren ist, lesen Sie dann.
[1] Sommerville, I.: „Software Engineering”, Pearson Verlag, 2012
[2] Balzert, H.: „Lehrbuch der Softwaretechnik“, Spektrum Verlag, 2011
[3] Bächle, M.; Kolb, A.: „Einführung in die Wirtschaftsinformatik“, Oldenbourg Verlag, 2012
[4] Kühnl, A.: „Visual C# 2012. Das umfassende Handbuch“, Rheinwerk Computing, 2013
Dieser Artikel ist im Entwickler Magazin erschienen.
Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.
Unsere Redaktion empfiehlt:
Wochenrückblick: Bash-Integration unter Windows 10, Zend Framework 3 & AntMe!
Relevante Beiträge
Rust Foundation gegründet: Microsoft, AWS, Google, Huawei und Mozilla als Board Member
Von Jean Kiltz 2 Wochen online
2020 Tech Lead Survey: Digitale Transformation im Eiltempo
Von Maika Möbus 2 Wochen online
Legacy, IoT und Women in Tech – Unsere Highlights der Woche
Legacy-Software als Teufelskreis: Darum ist regelmäßige Softwarepflege ein Muss
Von Nadine Riederer 3 Wochen online
Gut getestet läuft besser: Das ServiceNow Automated Test Framework
Von Martin Mohr 4 Wochen online
Entwickler-Mindsets, Angular 11.1 und KI-Bias – Unsere Highlights der Woche
Von Jean Kiltz 1 Monat online
Einführung i.d. Programmierung: Datenbanken & Datenmodellierung
[…] Software: Qualität vs. Release-Termin – was geht vor?Einführung in die Programmierung: Struktur sorgt für QualitätAntMe!: Spielerischer Einstieg in die ProgrammierungEinführung in die Programmierung: Das Aussehen […]
entwickler.de
JAXenter.de
JAXenter.com
International PHP Conference
International JavaScript Conference
webinale
MobileTech Conference
Internet of Things Conference
DevOpsCon
API Conference
Machine Learning Conference
Leserservice & Kontakt
Anzeigenservice & Werbung
Entwickler Akademie
Über S&S Media
Software & Support Media GmbH
Datenschutz-Shop
- Gib Deinen Standort ein -
Erhalte Deinen aktuellen Standort