Softwarearchitekt

+ andere TechDocs
+ SW-Dokumentation
+ Vorgehensmodelle
+ UML, MDA
+ Patterns
+


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.




Weitere Themen: andere TechDocs | Vorgehensmodelle | UML, MDA | Patterns
© 2002-2007 Torsten Horn, Aachen