Der folgende Text stellt eine verkürzte Sammlung von Stichworten zu Themen dar, die Softwarearchitekten und Softwarearchitekturen betreffen.

Weiteres zu diesen Themen finden Sie auch auf den Webseiten:
- Dokumentation im Softwareentwicklungsprozess
- Vorgehensmodelle zum Softwareentwicklungsprozess
- UML / MDA
- Patterns

Inhalt

1. Umfeld des Softwarearchitekten
   
2. Architektursichten
   
3. Architekturkonzepte
   
4. Muster, Patterns
   

Umfeld des Softwarearchitekten

Anforderungsanalyse

Die Anforderungsanalyse (Pflichtenheft) wird typischerweise nicht vom Softwarearchitekten, sondern vorher von der Fachabteilung durchgeführt. Der Softwarearchitekt prüft lediglich auf ungenaue Formulierungen oder widersprüchliche Anforderungen.

Unterschieden wird:

- Fachliche Anforderungen (Funktion für Anwender) versus
  technische Anforderungen (technische Umsetzung),

sowie

- Funktionale Anforderungen (Aktionen des Produkts) versus
  nicht-funktionale Anforderungen (Eigenschaften des Produkts, z.B. Bedienbarkeit, Performance, Zuverlässigkeit, Wartbarkeit, Kosten)

Beantwortet werden müssen folgende Fragen:

- Kernaufgaben?

- Nutzung wie und von wem?

- Schnittstellen?

- Welche Daten?

- Darstellung?

- Steuerung?

- Eigenschaften?

Definition "Softwarearchitektur"

Definition (angelehnt an IEEE 1471 sowie an Booch/Rumbaugh/Jacobson):
Grundlegende Organisation eines Softwaresystems, die Beziehungen seiner Komponenten untereinander und zur Umgebung sowie die grundsätzlichen Richtlinien zum Entwurf und zur Entwicklung.

Dies beinhaltet signifikante Entscheidungen über:

- den leitenden Architekturstil

- die Organisation des Softwaresystems

- die Auswahl der Strukturelemente und Schnittstellen

- deren spezifiziertes Verhalten

- deren Komposition

Vorteile einer expliziten Softwarearchitektur-Planungsphase

Organisatorische Vorteile:

- Expliziter und definierter Übergang zwischen Analyse und Realisierung

- Sicherstellung der Erfüllbarkeit der Anforderungen und Qualitätsansprüche

- Bessere Definition, Dokumentation und Vermittlung des Gesamtkonzept

- Klarere Aufteilung der Arbeit in definierte Blöcke

Technische Vorteile:

- Bessere Beherrschung der Komplexität durch klar definiertes Konzept

- Höhere Chancen für Wiederverwendung, Testbarkeit, Flexibilität, Erweiterbarkeit, Wartbarkeit

Aufgaben des Softwarearchitekten

Der Softwarearchitekt ist zuständig für:

- Kommunikation mit Kunde, Fachabteilung, Projektleitung, Entwicklung, Test

- Anforderungsmanagement: Ungenauigkeiten und Widersprüche aufdecken, Kompromisse finden, Akzeptanzkriterien definieren

- Entscheidungen treffen, obwohl noch nicht alle Voraussetzungen und Fakten geklärt sind

- Analyse und Design

- Gestaltung der Softwarearchitektur

- Machbarkeitsanalyse (Durchstich, Proof of concept)

- Technische Risikoanalyse

- Iterationsplanung / Milestonesplanung für die Umsetzung

- Implementierung und Environment

- Beratung und Unterstützung für andere Projektbeteiligte, z.B. Entwickler

Softwareentwicklungsprozess, Vorgehensmodell

Definiert Rollen (Verantwortlichkeiten), Phasen, Aufgaben, Aktivitäten, Methoden und Dokumente (Artefakte, Arbeitsergebnisse).

Beispiele für Vorgehensmodelle: XP (Extreme Programming), RUP (Rational Unified Process), OEP (Object Engineering Process), V-Modell, Wasserfallmodell.

Hilfreich sind meistens folgende Vorgehensdetails:

- Kommunikation und Dokumentation möglichst mit standardisierter Notation mit definierter Semantik (meistens UML)

- zyklisch / iterativ

- Komplexität reduzieren durch Modularisierung, Kapselung, Komponenten

- Wiederverwendung, Design Patterns, MDA

- frühe Prototypen sowie frühzeitige, regelmäßige und automatisierbare Tests

- Anwendung verschiedener Sichten (siehe unten: Anforderungssicht, Systemkontextsicht, Systemdesignsicht, Implementierungssicht, Infrastruktur- und Verteilungssicht, Informationsfluss- und Datensicht)

UML

Unified Modeling Language, begründet von den drei Amigos (Booch, Rumbaugh und Jacobson), seit 1997 Standard der OMG, seit 2000 mit UML 1.3 auch ISO-Standard und seit 2003 mit UML 2.0 um MDA erweitert. UML ist keine Methode, sondern definiert eine Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die Geschäftsprozessmodellierung und für die objektorientierte Softwareentwicklung. Vereinheitlichung von Software-Programmiersprachen, Spezifikationen von verteilten Anwendungen, objektorientierte Analyse und Design sowie Systemmodellierung. Z.B. mit Tools von Rational Software / IBM, Together / Borland, Poseidon / Gentleware.
Weiteres zu UML und den 13 Diagrammtypen der UML 2 siehe: uml.htm

MDA

Model Driven Architecture, Standard der OMG. Definiert Vorgehensweise beim Softwareentwicklungsprozess. Verwendet UML, trennt PIM (Platform Independend Model) und PSM (Platform Specific Model) und bietet eine Grundlage für automatische Code-Generierung.
Weiteres zu MDA siehe: uml.htm#MDA

Architektursichten

Anforderungssicht

Nach außen sichtbares Verhalten. Was soll das System leisten?

UML-Anwendungsfalldiagramm (Use Case Diagram).

Systemkontextsicht

Grober Überblick über logischen Aufbau des Systems sowie nach außen sichtbare Struktur und Schnittstellen / Kommunikationspfade.

UML-Komponentendiagramm.

Systemdesignsicht

Interner Aufbau und Funktionsweise des Systems, Struktur und Dynamic, Logical View.
Fast alle UML-Diagramme.

Statische Systemdesignsicht:
Ähnlich Systemkontextsicht, aber diesmal Innenleben des Systems.
UML-Klassendiagramm, UML-Komponentendiagramm, Schnittstellendefinitionen, OCL.

Dynamische Systemdesignsicht:
Zusammenspiel der Systembestandteile.
EPK, UML-Aktivitätsdiagramm, Interaktionsübersichtsdiagramm (Variante des Aktivitätsdiagramms), Zustandsdiagramm, Sequenzdiagramm, Kommunikationsdiagramm, Timingdiagramm.

Kooperationen in der Systemdesignsicht:
Wie arbeiten Instanzen zusammen? Strukturierung, Diagrammgruppierung, Muster, Instanzrollen. Zusammenhang der Interaktions- und Strukturdiagramme.
UML-Kompositionsstrukturdiagramm.

Implementierungssicht

Paketaufteilung, organisatorische Aspekte, Realisierungsabhängigkeiten, Konfigurationsmanagement.

UML-Paketdiagramm, UML-Komponentendiagramm.

Infrastruktur- und Verteilungssicht

Betreibersicht, Deployment (Verteilung) der Artefakte (Arbeitsergebnisse, z.B. Document, File, Software, «executable», Script, Source, Library) und Zuordnung zu Knoten (z.B. Rechner, Server, «device», «container», OS, DB, EJB, Workflow).

UML-Verteilungsdiagramm.

Informationsfluss- und Datensicht

Welche Daten mit welchen Datenstrukturen werden im System gespeichert und ausgetauscht?

UML-Datentypen (Attribute und Operationen), UML-Komponentendiagramm, UML-Kommunikationsdiagramm.

Architekturkonzepte

Umfeld

Rahmenbedingungen, vorhandene Erfahrungen, mögliche Wiederverwendung.

Anforderungsanalyse (fachliche und technische Anforderungen, funktionale und nicht-funktionale Anforderungen).

Anforderungen müssen priorisiert und gewichtet werden (am besten vom Stakeholder: mindestens nützlich/unwichtig/unakzeptabel, besser Scoring).

Bewertung der Anforderungen nach Machbarkeit, Kosten und Aufwand.

Bewertung vergleichbarer Softwarearchitekturen mit Scoringtabelle.

Durch Architektur beeinflussbare Qualitätsmerkmale einer Anwendung: Funktionalität, Benutzbarkeit, Zuverlässigkeit, Wartbarkeit, Flexibilität, Effizienz, Performance (siehe auch ISO 9126).

Architekturstile

Ein Architekturstil befasst sich mit der Architektur "im Großen" als grobe Skizze und Betrachtung des Gesamtsystems.

Wichtiges Ziel: Reduktion und Beherrschung der Komplexität.

Im Vergleich zu Architekturmustern und Architekturaspekten ist die Sicht grober und der Abstraktionsgrad höher.

Wichtige Stile und Stilaspekte: Komponenten, logische und physische Verteilung, Layering sowie daten- und ereignisorientierte Ausrichtung.

Architekturstil: Komponenten

Komponenten sind in sich schlüssige entweder allein ablauffähige oder durch andere Softwareeinheiten verwendbare Softwareeinheiten.

Komponenten sind wiederverwendbare und eigenständig vermarktbare Softwareeinheiten, die in vorher nicht planbaren Kontexten eingesetzt werden.

Komponenten haben definierte Schnittstellen und können einfach kombiniert und leicht ausgetauscht werden.

Komponenten sind ein wichtiges Mittel zur Komplexitätsbeherrschung.

Qualitäten einer Komponente: große Kohäsion (innerer Zusammenhalt), schwache Kopplung (über definierte Schnittstellen), Offenheit für Erweiterungen, Geschlossenheit für Änderungen.

Beispiele: SOAP Web Services, CORBA, Java (JavaBeans, EJB), .NET-Komponenten, COM (VBX, OCX, ActiveX), Delphi-Komponenten.

Architekturstil: logische und physische Verteilung

Verteilungsgrundlage bilden Komponenten.

Client/Server-Architektur, Thin Client (z.B. Webbrowser), Fat Client (z.B. mit Server gekoppeltes Windows-Programm).

n-Tier-Architektur (z.B. DB + Application Server + Präsentation).

Peer-to-Peer-Architektur (entweder mit zentralem assistierenden Server oder vollständig dezentral).

Verteilungsmuster Broker (Vermittler für verteilte Dienste, z.B. über CORBA, Common Object Request Broker Architecture).

Architekturstil: Layering

Oft die drei Schichten
- Infrastruktur (DB, Sicherheit, Verteilung, Integration, Kommunikation, Netzwerk)
- Fachlogik (z.B. Application Server)
- Präsentation (z.B. GUI, Webbrowser).

Schichten sollen unabhängig voneinander sein und dürfen nicht durchbrochen werden. Jede Schicht kennt nur die Schnittstellen ihrere Nachbarschichten. Jede Schicht darf nur die direkt darunter liegende Schicht benutzen.

Reduzierte Komplexität, bessere Verständlichkeit, Wartbarkeit und Erweiterbarkeit.

Architekturstil: daten- und ereignisorientierte Ausrichtung

Datenorientierte Systeme:
Fokus auf der Bearbeitung großer komplexer Datenmengen, z.B. bei ERP und CRM.

Ereignisorientierte Systeme:
Fokus auf Ereignissen und Kommunikation, z.B. bei Automatisierungssystemen, Embedded Systemen und Fahrzeugsteuerung.

Reactor-Muster:
Ereignisgesteuerte Anwendung mit mehreren Dienstanfragen gleichzeitig, die synchron und seriell verarbeitet werden.
Vorteile: Trennung von Auslösung und Abarbeitung, Modularität, Konfigurierbarkeit, keine Nebenläufigkeit.
Nachteile: keine rechenintensiven Operationen, eingeschränkte Anwendbarkeit, schwierig zu debuggen.

Architekturmuster

Muster (Patterns) beschreiben häufig auftretende Entwurfsprobleme und dazu universell verwendbare generische Lösungsschemen.
Weiteres siehe Muster, Patterns.

Architekturaspekte

Architekturaspekte befassen sich mit der Architektur "im Kleinen", also mit Details.

Im Vergleich zu Architekturstilen ist die Sicht feiner und der Abstraktionsgrad kleiner.

Zum Beispiel: Rahmenbedingungen, Hardware, Betriebssysteme, Infrastruktur, Sicherheit, Verteilung, Datenhaltung, Workflow, Fehlerbehandlung, Benutzeroberflächen, vorhandene Komponenten und Bibliotheken, Schnittstellen, UML-Programmiersprachenabbildung, automatische Codegenerierung.

Schnittstellen / Interfaces

Schnittstellen / Interfaces sind ein wichtiges Hilfsmittel zur Modularisierung und Komponentenbildung.

In der Design-Phase werden Schnittstellen definiert.
Analogie zwischen den Dreiteilungen:

	Analyse	:	Design	:	Implementierung
	Fachklasse	:	Interface	:	Komponente

Die Schnittstelle kann als Vertrag, Verbindlichkeit und Normung aufgefasst werden und übernimmt eine Vermittlerrolle.

Benutzeroberfläche

Mögliche Zielsysteme: Windows, Linux, X-Window, Webbrowser, Java-Applet, PDA, Handy, Terminal, Kommandozeile.

Bestimmte erwartete Oberflächenparadigma? Bedienung von Laien oder Experten? Wizard-Assistenten oder direkte Dialoge?

Mehrsprachigkeit?

MVC-Muster (Model-View-Controller) zur Entkopplung von Fachobjekten und deren Darstellung.

Datenhaltung

Gibt es zu berücksichtigende bereits bestehende Systeme?

Wird Offline-Datenhaltung mit Replikation/Synchronisation benötigt?

Anforderungen: Antwortzeiten, Performance, Transaktionen, Sicherheit, Backup.

Datenhaltungsarten: Datei, XML, objektorientiert (OO), relational (SQL), verteilte Datenbank.

Verteilung

Reicht Datenübertragungsrate zwischen Rechnern? Ist Datenverbindung zuverlässig?

Gelten Sicherheitsregeln? Muss Offline-Betrieb möglich sein?

Wie entfernte Objekte finden, identifizieren, erzeugen, löschen?

Wie Methoden entfernter Objekte aufrufen?

Datenkonvertierung, Umrechnung, Konvertierung zwischen Little / Big Endian?

Verteilung und Kommunikation soll sein:
transparent, herstellerunabhängig, plattformunabhängig, programmiersprachenunabhängig.

Z.B. mit CORBA lassen sich diese Ziele erreichen.

Auch das Proxy-Muster hilft, Objekte zu entkoppeln.

Sicherheit

Anmeldung am System? Rollen? Berechtigungen? Für Funktionen und/oder Daten? Bestehende Rechtesysteme?

Firewall, Verschlüsselung, Authentifizierung, Zertifizierung, Sicherheits-Hardware (Chipkarte, Token)?

Transaktionen

Wodurch kann Transaktion scheitern? Wie ist dann zu reagieren?

Vorhandene Mechanismen und Werkzeuge?

Kapselung durch Transaktionsobjekte, die alle beteilgten Fachobjekte kennen und koordinieren?

Workflow

Wie flexibel und konfigurierbar? Anwenderführung? Workflowmanagementsystem?

Fehlerbehandlung

Einheitliches Konzept zur konsistenten Fehlerbehandlung, für Fehler-Logs und Fehlermeldungen.

Prototyping

Entweder Wegwerf-Prototyp (schnell entwickelt, Proof of concept) oder evolutionärer Prototyp (wird weiterentwickelt).

Kann zur Bewertung von Lösungsalternativen dienen sowie zur Überprüfung von:
- fachlichen Spezifikationen (Benutzerschnittstelle, Interaktionsstil, Fachlogik, Ablauf) oder
- technischen Spezifikationen (Architekturentscheidungen, GUI-Style-Guide, Performance, technische Funktionen, Schnittstellen).

Bereits in der frühen Prototyp-Phase sollten Schnittstellen für automatische Tests implementiert werden.

Technologien

Hardware (z.B. Embedded, Mobil, PC, Workstation, Server, Mainframe)

Betriebssysteme (z.B. Windows, Linux, Unix, Echtzeitbetriebssystem)

Plattformen (z.B. Application Server, Java EE, .NET)

Komponentenmodelle bzw. verteilte Systeme (z.B. mit SOAP Web Services, CORBA, EJB, DCOM)

Programmausführungsart (z.B. Exe, Dll, Webapplikation, Skript, embedded)

Art der Codegenerierung (z.B. MDA, RAD, 4GL)

Objektorientierte Programmiersprachen (z.B. Java, C#, Delphi, Smalltalk, Eiffel)

Prozedurale Programmiersprachen (C, COBOL, Fortran, PL/1, Assembler)

Andere Programmiersprachen (Mischsprachen wie PHP, Datenbanksprachen wie SQL, Markup-Sprachen wie HTML / XML, deklarative Sprachen)

Third-party Software (z.B. Bibliotheken, Klassenbibliotheken (wie MFC), Komponenten, Frameworks)

Muster, Patterns

... siehe Muster, Patterns.