home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

Guter Softwarearchitektur?

Die ISO 9126 beschreibt gute Softwarearchitektur, d.h. die Anwendung ist funktional, läuft stabil, ist langlebig, lässt sich einfach warten, ist portierbar und lässt sich mit wenig Aufwand um weitere Funktionalität erweitern. Für gute Softwarearchitektur ist es aber auch wichtig Software Termingerecht fertig zustellen und das Budget einzuhalten.

ISO 9126

ISO 9126

Funktionalität (Welche Funktionen beherrscht die Anwendung), Zuverlässigkeit (Gibt es Abstürze?), Wartbarkeit (Lässt sich die Anwendung einfach erweitern?), Benutzbarkeit (Wie einfach lässt sich die Anwendung bedienen?), Portabilität (Ist die Installation einfach? Unterstützung von verschiedenen Betriebssystemen?), Effizienz (Wie geht die Anwendung mit Systemressourcen um?).

Was macht ein Architekt?

Ein Architekt sorgt für Flexibilität und Einfachheit, sowie für das richtige Maß zwischen Performance und Wartbarkeit. Er baut eine Brücke zwischen den Anforderungen und der Implementierung.

Sein Vorgehen dabei:

  • Beschreiben der Architekturziele
  • Aufgabe (Anforderungsdokument) analysieren und abstrahieren
  • Grobplanung (Zerlegung in Komponenten)
  • Zusammenspiel der Komponenten definieren
  • Feinplanung
  • Bestehendes auf Wiederverwendbarkeit prüfen

    • Datenbanken, Datenzugriffskomponenten (ADO)
    • GUIBibliotheken
    • Bestehende "Baupläne" (Architektur-, Designpattern)
    • Frameworks

  • Prüft Einhalten der Standards
  • Spezifiziert die Tests

Was sollte ein Architekt für Fähigkeiten besitzen?

Ein Architekt muss gut mit anderen Menschen kommunizieren können. Anforderungen des Auftraggebers muss der Architekt aufnehmen, aufteilen und verteilen. Er muss über Gesetzte, Normen und Standards (z.B. ISO 9126) Bescheid wissen um diese später zu berücksichtigen. Der Architekt muss Verständnis über Projektmanagement besitzen um die anfallenden Ressourcen, wie Zeit, Geld und Leute, besser planen zu können. Der Architekt muss Kenntnisse über Werkzeuge, Patterns und Technologien besitzen.

Seperation of Concerns

Aufteilung eines Programms in Teile, die sich möglichst wenig überschneiden. Vgl. Kirchenbau: Die Kirchenwand sollte keine doppelte Funktion haben.

Quelle: http://www.it-infothek.de/fhtw/grund_wi_05.html

V-Modell

Der Architekt spezifiziert tests nur bei einem Vorgehen nach dem V-Modell. Dabei arbeitet er in den Phasen funktionaler Systementwurf, technischer Systementwurf, Komponenten Spezifikation, (Komponententest), Integrationstest und Systemtest. Die Kerntätigkeiten des Architekten liegen in Systementwurf und Komponenten Spezifikation.

Wie geht ein Architekt vor?

Er analysiert die Ziele und Aufgaben. Danach folgt die Grobplanung, in der das große Ganze in einzelne Komponenten zerlegt wird. Anschließend wird in der Feinplanung die vorherige Grobplanung detaillierter geplant und Lösungen verfeinert. Der Architekt muss sicherstellen, dass Standards eingehalten werden. Er spezifiziert Tests für die spätere Implementierung und Testverfahren.

Unterschied Bau- und Softwarearchitektur

Bauarchitektur:Softwarearchitektur:
materiellimmateriell
Keiner würde auf die Idee kommen kurz vor der Fertigstellung des Hochhauses das Fundament neu zu machen.Anspruch auf Änderbarkeit, bis kurz vor der Fertigstellung werden Grundlegende Dinge geändert.
Technologie ändert sich kaum, es gibt nicht von heute auf morgen ein neuen Baustoff.Technologien ändern sich rasend, jeder möchte das neuste verwenden obwohl kaum Know-how da ist.
Bauarchitektur ist eine Jahrtausend alte Disziplin
  • Viele anerkannte Abschlüsse

  • Menschen besitzen viel Erfahrung in diesem Gebiet

  • Hohe Industrialisierung (Fertighäuser)

Geschäftsprozesse werden ständig optimiert, neue Märkte tun sich auf.
Softwarearchitektur gibt es erst seit einigen Jahrzehnten
  • Kaum Abschlüsse , Studiengänge und Zertifikate

  • Kaum Erfahrung in diesem Bereich, neue Software ist „einzigartig“

  • Keine Industrialisierung (keine Fließbandarbeit)

 

Architekturprozess

Ablauf des Architekturprozesses

Anforderungen

In den Anforderungen werden Funktionale und nicht funktionale Anforderung festgelegt. Die Anforderungen umfassen fast alle Punkte aus ISO 9126, Funktionalität / Functionality, Zuverlässigkeit / Reliability, , Benutzbarkeit / Usability, Portabilität / Portability und Effizienz / Efficiency.

Die Anforderungen werden vom Auftraggeber festgelegt, decken jedoch nicht alle Punkte von ISO 9126 ab. Wartbarkeit / Maintainability wie auch Portability und Efficiency werden oftmals vom Auftraggeber vergessen.

In den Anforderungen steht der Zeitpunkt wann das Projekt fertig sein soll, Funktionalität mit Hilfe von Use Cases, welche Art von Client (Thin Client: nur die Ein- und Ausgabe erfolgt auf dem Client, Fat Client: auch die Verarbeitung der Daten geschieht auf dem Client), MTBF (Mean Time Between Failure) wie häufig dürfen Fehler auftreten, wie groß darf die Reaktionszeit auf Anfragen an das System sein (auch in Abhängigkeit von Benutzeranzahl), wie werden Fehler protokoliert oder sichtbar gemacht.

In den Anforderungen werden bereits erste Tests festgelegt, Integrationstests (Integrationstrategie: Big Bang, Botem Up, Top Down) und Systemtests.

Einflussfaktoren

Einflussfaktoren wie Maintainability (Wartbarkeit, Änderbarkeit, Testbarkeit), Portability und Efficiency werden vom Architekten spezifiziert.

Organisatorische Faktoren:

  • Managment: Make or Buy Decision (z.B. Soll die Handschriftenerkennung selbst programmiert werden oder wird diese Funktionalität von einem Drittanbieter eingekauft), auch COTS genannt (commercial off-the-shelf) (englisch für Kommerzielle Produkte aus dem Regal)

  • Team, Mitarbeiter: Welche Fähigkeiten, Technikkentnisse besitzen die einzelnen Mitarbeiter, welches Domänenwissen haben sie.

  • Zeitplan zur Realisierung der Software.

  • Welches Geldbudget steht zur Verfügung?

Technologische Faktoren:

  • Welche Hardware, welches Betriebssystem, welcher Prozessor wird eingesetzt, wie viel Arbeitsspeicher steht zur Verfügung, wie ist die Netzwerkstruktur, Netzwerkauslastung.

  • Welche Protokolle werden zur Kommunikation eingesetzt.

  • Welche Software wird verwendet, welches Datenbanksystem kommt zum Einsatz, werden Frameworks (z.B. Struts, Hibernate,...) verwendet, welche Programmiersprachen, welche Dokumentenformate (z.B. *.doc, *.mp3, ...).

  • Welche Architekturstile, Architekturmuster sollen eingesetzt werden (Entwurfsmuster / Patterns)

Architektur

In der Architektur wird Basiswissen (siehe Bild Basiswissen), Domänenwissen (spezielles Wissen über ein Fachgebiet, z.B. Bankenwesen, Gesundheitswesen, Gesetzestexte), Heuristiken (siehe weiter unten) verwendet.

Basiswissen Johner Architekturscript 2, Seite 7

Heuristiken

Heuristiken werden auch "best practices" genannt, sozusagen "Tipps und Tricks" , eine Erfahrungssammlung von Experten.

  • So einfach wie möglich entwerfen
  • Angemessen komplex modelieren
  • Nicht übergeneralisieren, z.B. vom Mensch über Arbeiter über Student...
  • Auf Schnittstellen konzentrieren

(Auszug Heuristiken Johner Architekturscript 2, Seite 8)

Validierung

In der Validierung werden Reviews gemacht, Messungen vorgenommen und auf Metriken geprüft.

In Reviews wird geprüft ob der Architekturstil zur Anforderung passt, ob alle Anforderungen umgesetzt wurden (Traceability), ist immer noch alles verständlich und einfach gehalten, wurden die Entwurfsprinzipien durchgängig eingehalten. Prototyp wird die Effizienz gemessen, wie viele Ressourcen werden verbraucht, wie ist die Reaktionszeit, lässt sich der Prototyp auf andere System portieren? Bei der Metrik Prüfung wird geschaut ob Abhängigkeiten zwischen Komponenten/Modulen untereinander bestehen. Prüfung der dynamischen UML Diagramme (wie Use Case, Sequenz)

Quelle: http://de.wikipedia.org/wiki/Bild:GR-Erdgeschoss.jpg
Johner Script 3, Seite 6

Architekturelle Sichten

Ein Bauarchitekt sieht nur die Wände in einem Grundriss, die Hausbesitzer stellen sich den Grundriss bereits mit Möbeln vor, ein Elektriker sieht nur die verlegten Kabel. Sowie Bauarchitekt, Hausbesitzer und Elektriker verschiedene Sichten auf das ein und selbe Objekt besitzen, kann man auch verschiedene Sichten auf Software besitzen.

Sichten sind verschiedene Perspektiven die man auf die Software haben kann. Sichten reichen von der allgemeine Sicht, die die Software fachlich auf spezifikation Ebene betrachtet, bis hin zur konkreten Sicht, die die Software zur Laufzeit betrachtet.

Es gibt die fachliche Sicht, sie ist Plattform und Technonlogie unabhängig, in ihr werden beispielsweise Klassendiagramme erstellt um einen ersten Eindruck von der Software zu bekommen. In der technischen Sicht werden bereits Datentypen spezfiziert, Datenbankschemen erstellt. In der Laufzeitsicht steht die Software zur Verfügung, z.B. als Jar-Datei.

Architekturdokument

Das Architekturdokument enthält folgende Punkte

  • Ein Inhaltspunkt vom Arichtekturdokument ist die Anforderungsanalyse, ist diese bereits erstellt sollte im Architekturdokument darauf hingewissen werden.
  • Einflussfaktoren (siehe Script weiter oben)
  • Tests

    • System-, Integrations- und Komponententests

  • Risikomanagment

    • nur in Bereich in denen Menschenleben gefährdet werden können durch unsere Software, z.B. Krankenhaus
    • wie groß ist die Wahrscheinlichkeit, dass ein Fehler Auftritt der für Menschen gefährlich ist, welches Risiko hat der Fehler auf den Menschen

  • Richtlinien für Programmieren

    • Coding Guidelines, Metriken,

  • angestrebte Architektur

    • COTS commercial off-the-shelf, was kann eingekauft werden
    • welche Komponenten und Schnittstellen wird meine Software verwenden
    • Beziehung und Kommunikation zwischen Komponenten

      • Technologien, Protokolle

    • spezielle Aspekte

      • persistenz

        • Datenbanksystem
        • File-Format

      • Fehlermanagment, werden Exceptions an Ort und Stelle gefangen oder gibt es einen zentralen ExceptionHandler
      • Logging, wie dokumentiere ich Fehler
      • Security, wie schütze ich den Zugriff auf (sensible) Daten

Die genau Auflistung des Dokuments ist im FDA Artikel beschrieben, Link

Schlanke Schnittstellen

Für schlanke Schnittstellen müssen wir darauf achten nur wenige Zugriffsmethoden nach außen preiszugeben und die Parameter, einer nach außen sichtbaren Methode, möglichst gering zuhalten.

Besitzt eine Methode unzählige Paramater, müssen bei der kleinsten Änderung alle Parameter mitübergeben werden, obwohl die meisten Parameter sich nicht geändert haben. Auf der anderen Seite ist es nur sehr schwer die Methode auszutauschen, da ein Entwickler die Parameter in ihrer Reihenfolge genau kennen muss.

Verfeinerung des UML Klassendiagramms im Zuge des Architekturentwurf

Schritt 1
Schritt 2
Schritt 3

Rasch ändernde Funktionalität

Funktionalität die sich häufig ändert (Beispiel Hund, Grundstück und Steuern: Steuern ändern sich häufig) wird in eine neue Klasse ausgelagert. Damit wird die Wartbarkeit verbessert, da es eine zentrale Klasse gibt in dem die Hundesteuer definiert wird.

Lists versus Sets

 

ListsSets
kein Schlüsselkein Schlüssel
Reihenfolge wird eingehalten, d.h. man kann auf Elemente mit der Methode get(int position) zugreifenkeine Reihenfolge, d.h. um auf ein Element zuzugreifen muss man über das ganze Set iterieren bis man das gesuchte Element gefunden hat
Duplikate können vorkommenbesitzt kein zwei gleichen Elemente



Johner Script, Stunde 5, Seite 1

Maps

Maps besitzen einen Schlüssel, der Zugriff auf ein Element in der Map geschieht mit diesem Schlüssel. Hashtable, HashMap und TreeMap implementieren das Interface Map. Ein TreeMap ist eine sortierte Map, die TreeMap wird aufsteigend nach dem Shclüssel sortiert.

Eigenschaften einer guten Suchfunktion

Die Suchmethode sollte nicht in ihrer Aufrufparameter begrenzt sein, eine Suchethode wie

  public Angestellter suche(String name, String personalNr, String haarfarbe,
 String koerpergroesse, String abteilung, String gehalt
) {
    ...
  }

führt leicht dazu dass man Parameter beim aufrufen vertauscht oder sich vertippt. Gegen Tippfehler helfen Enums, bsp. Abteilungs Enum:

public enum Abteilung {
  ENTWICKLUNG, PERSONAL, BUCHHALTUNG, MARKETING;
}

Noch besser ist es statt vielen einzelnen Parametern eine Klasse zu übergeben.

  public Angestellter suche(Angestllter gesuchterAngestellter) {
    ...
  }

1:1 und 1:n Beziehungen

Bei 1:1 (1 zu 1) Beziehung wird das andere Objekt wie gewohnt instanziert. Ein Auto besitzt ein Fahrer.


Bei 1:n Beziehungen benötigt man einen Datenstruktur die beliebig viele Objekte aufnehmen kann. Mit Collections kann man 1:n Beziehungen darstellen. Ein Auto besitzt viele Räder (ob es richtig ist dass ein Auto tatsächlich beliebig viele Räder hat muss seperat geprüft werden z.B. beim einfügen von einem neuen Rad muss geprüft werden ob die maximale Anzahl von Rädern erreicht ist).

import java.util.ArrayList;
import java.util.List;

public class Auto {

  public Auto() {
    Fahrer fahrer = new Fahrer();        // 1:1 Beziehung
    
    List<Rad> raeder = new ArrayList<Rad>();  // 1:n Beziehung
  }

}

Warum teilt man Anwendungen in verschiedene Schichten ein?

Präsentation (Präsentationschicht), Logik (Anwendungschicht) und Datenhaltung (Datenschicht) sollen von einander unabhängig sein.Durch diese Strukturierung wird der Code besser wartbar und die einzelnen Schichten lassen sich bei Bedarf austauschen. Beispielsweise möchte man die vorhandene Präsenationsschicht, zur Zeit eine SWT Gui durch eine webbasierende GUI ersetzen.

Die Anwendung wird durch die Schichten skalierbar, lässt sich somit als Thick oder Thin Client betreiben.

Technologien für die Präsentationschicht

Schicht in der die Datenpräsentation, Datenein- und ausgabe stattfindet. Mögliche Technologien sind JSP, JSF, HTML.

Aufgabe der Anwendungsschicht

Die Anwendungsschicht enthält die Geschäftlogik des Programmes.

Beispiel für eine Mehrschichtigeanwendung

Online Banking.

Bild folgt

FatClient Vorteile und Nachteile

VorteileNachteile
Netzanbindung an den Server ist nicht unbedingt notwendigAufwendige Installation auf dem Client
weniger NetzwerklastSoftware ist Client spezifisch (lässt sich womöglich nicht unter allen Betriebsystem zum laufen bringen)
Ressourcen des Clients (CPU, Grafikkarte) lassen sich besser benutzenAufwendige Updates
Datenvalidierung kann direkt am Client ablaufendezentrale Datensicherung
Rechenlast lässt sich auf die Clients verteilengeringer Schutz vor Schadprogramme, da jeder Client gefährdet ist

Anwendungsfälle für Fat Clients

  • Anspruchsvolle GUI (z.B. 3D Anwendungen)
  • Zugriff auf Hardware oder Peripherie des Clients notwendig
  • Hohe Netzwerklast, Datenvolumina
  • Verteilung von Rechenlast

Thin Client Vor und Nachteile 

VorteileNachteile
keine Installation notwendighohe Netzwerkverfügbarkeit notwendig und Netzwerklast
höhere Unabhängigkeit von Hardware und Betriebssystemkein Zugriff auf Client Hardware, Peripherie
einfache Softwareverteilung und UpdatesServer wird stärker belastet da alle Clients ihm die Rechenlast übertragen
Zentrale DatensicherungGUI ist langsamer
Dateninkonsistenz unwahrscheinlicher, da Daten ständig mit dem Server abgeglichen werden
Restriktive Beschränkung des Clients
Hoher Schutz gegen Schadprogramme

Anwendungsfälle für Thin Clients

  • eignet sich für heterogene Systeme

    • PDA, Telefon, PC
    • verschiende Betriebsysteme, unterschiedliche Hardware

  • wenn sehr viele Clients vorhanden sind

MDA

MDA steht für Model Driven Architecture. MDA verfolgt das Konzept mit Modellen und Generatoren automatisch Code zu erzeugen und damit die Entwicklungsgeschwindigkeit zu erhöhen.

Es wird zunächst ein Plattform unahängiger Entwurf erstellt (PIM, plattform indepent model), aus diesem Entwurf wird dann ein Plattform spezifischer Entwurf erstellt (PSM, plattform specific model). Aus dem PSM wird anschließend Code und Doku erzeugt.

Quelle: http://javamagazin.de/itr/online_artikel/psecom,id,408,nodeid,11.html

Wie unterscheidet sich MDA von der Codegenerierung?

Mit MDA soll nicht der vollständige Code generiert werden, sondern nur dort wo es sinnvoll ist. Zunächst wird ein Plattform unabhängiges Modell erzeugt (PIM), anschließend lassen sich ein oder mehrere Plattform spezifische Modelle generieren (PSMs).

MDA besitzt einen sehr hohen Grad an Interoperalität und lässt sich projektspezifisch anpassen.

Notationselemente UML

Die Notationselemente von UML werden in dem Meta-Model M2 beschrieben. Im M2 ist beschrieben wie Modelle aufgebaut, welche Elemente es gibt.

UML erweitern

Sollten einmal die in UML verwendeten Diagramme nicht weiterhelfen, da man etwas neues benötigt das bisher noch nicht vorhanden ist. Kann man auch selbst UML erweitern. Eine Stufe höher als M2 liegt M3 das Meta-Meta-Modell auch Meta Object Facility (MOF) genannt. M3 ist die Grundlage für M2 und beschreibt wie die Metamodelle in M2 aufgebaut sind. Dies kann man nutzen um sein eigenes UML Modell zu erstellen.

Quelle: http://de.wikipedia.org/wiki/Bild:M0-m3.png

Vergleich MDA mit Autobau

Wie beim Auto, werden vor der Fertigung Entwürfe gezeichnet die das Auto spezifizieren. Dabei gibt es verschiedene Sichten auf das Auto, die in den Entwürfen zur Geltung kommen. Die Entwürfe versteht ein Techniker von Porsche, wie auch ein Techniker von Ford. Sie sind überall verständlich, da die Element die im Entwurf eingesetzt werden standarisiert sind.

Warum kann es mehre PSMs geben?

Eventuell möchte man die Software auf unterschiedlichen Endgeräten nutzen, wie PC, Mac, Handy, PDA. Für jede Plattform wird dann ein spezifischer, Plattform abhängiger Entwurf angefertigt --> PSM.

Was spricht gegen MDA?

MDA ist sehr abstrakt, der hohe Grad an Abstraktion nimmt viel Zeit in Anspruch und rechnet sich damit nicht für kleiner Projekte. Triviale Probleme wie "berechne das Alter" müssen spezifiziert werden, obwohl bekannt ist wie das Problem gelöst wird.