Grundlagen und Prinzipien des Architekturentwurfs Flashcards
Charakterisierung: Softwarekomponenten
- klar definierte Schnittstellen
- definierte Abhängigkeiten zu anderen Komponenten
- können unabhängig von anderen Komponenten entwickelt werden
- Kapseln Teilsysteme
Wie wird ein System entworfen?
- Anforderungsspezifikation ist Ausgangspunkt für den Systementwurf
- Grobentwurf (Festlegung von Systemarchitektur und Komponenten)
- Feinentwurf (Softwarearchitektur der Komponenten)
- Entscheidende Rolle für
Entwicklungsprozess (Zerlegung eines Systems, arbeitsteilige Entwicklung,
Integration und Tests)
Qualitätseigenschaften (Komplexitätsbeherrschung, Performanz, Skalierung,
Wartbarkeit)
Gliederungskonzepte für Architekturen
- Klassen (als Typ-Konzept) legen fest, wie die Exemplare (Objekte) den
Nachrichtenaustausch zwischen Objekten mittels Methodenaufrufen
realisieren - Datenflusskomponenten beschreiben, wie die Komponenten durch das
Versenden von Nachrichten über Kanäle miteinandere kooperieren - Prozeduraufrufkomponenten kooperieren mittels Aufrufen von
Prozeduren in den an der Kommunikation beteiligten Komponenten
Schichtenarchitektur
System besteht aus Schichten, welche über/unter einander liegen und die informationen von unten nach oben verarbeiten.
z.B.
* Präsentationsschicht
* Applikationsschicht
* Datenschicht
Pro:
* Modular
* Vorteilhaft strukturierung
Con;
* Performance
Perspektiven des Architekturentwurfs
- Logische Architektur (beschreibt, welche Komponenten welche
Funktionalitäten übernehmen und wie sie funktional und logisch
zusammenwirken) - Realisierungsarchitektur (beschreibt, wie die logische Architektur
konkrete auf dem Software-/Hardwar-System realisiert wird)
Bestandteile der Architekturbeschreibung
Typische Bestandteile:
* Architekturanforderungen, Entwurfsziele und -prinzipien
* Systemgliederung in Komponenten
* Verbindung der Komponenten über Schnittstellen
* Schnittstellenbeschreibung der Komponenten
* Benutzungsschnittstelle des Gesamtsystems als Teil der Architektur
Welche Hardwarearchitekturen gibt es?
- Großrechnersysteme (gesamte Software läuft auf einem Rechner)
- Client/Serversysteme (Rechnernetz von Kleinrechnern/Clients und
Servern, Kommunkation durch Middleware)
Verteilte und nebenläufige Systeme
Verbunden durch ein Netzwerk und stellen Komponenten der Anwendung durch Middleware zur Verfügung
Interaktive verteilte Systeme
Interaktion durch Nachrichtenaustausch:
Unterscheidung zwischen:
* Synchroner Kommunikation (wartet auf Antwort)
* Asynchroner Kommunikation (Kann während des Wartens weitere Aufgaben bearbeiten)
Statik und Dynamik in Architekturen
- Dynamische Bestandteile (Zielen auf das Verhalten der Architektur (Wechselspiel
zwischen Komponenten, z.B. Protokolle) - Statische Bestandteile (Anzahl der Komponenten und
Kommunikationsbeziehungen, Darstellung durch Diagramme) - Statische Architekturen (Zahl der Komponenten und deren Verbindungen ändern
sich zur Laufzeit nicht) - Dynamische Architekturen (Zahl der Komponenten und deren Verbindungen
können sich zur Laufzeit ändern) - Statische Sichten (z.B. Klassendiagramme in objektorientierten Systemen)
- Dynamische Sichten (z.B. Objektdiagramme als Zustandsabbildung)
Aufgaben des Architekten
- Evaluierung unterschiedlicher Realisierungsalternativen (Entwicklerrolle)
- Koordination der Schnittstellen zwischen Teilprojekten (Entwicklerrolle)
- Entwicklung einer Systemvision (Analytikerrolle)
- Anforderungsbewertung (Analytikerrolle)
- Entscheidung über Systementwürfe (Projektmanagerrolle)
Prinzipien des Architekturentwurfs
(Strukturierung einer Architektur)
Zentrale Prinzipien zur Strukturierung einer Achitektur:
* Das Gebot der Einfachheit: KISS
* Kopplung und Kohäsion
* Kapselung und Information Hiding
* Separation of Concerns
KISS
Keep it simple and stupid (“Mache es einfach und nicht zu raffiniert”)
Kopplung
Kopplung: Abhängigkeiten zwischen Komponenten
* Beeinflusst die Wartbarkeit
* Maß zur Abschätzung der Auswirkungen von Änderungen im System
* Generell: Je niedriger die Kopplung, desto eigenständiger ist die Komponente oder das Modul.
Grundform Beispiel
Aufruf: A ruft B auf (A nutzt einen Service von B)
Erzeugung: A erzeugt B
Daten: A und B nutzen gemeinsame Daten/-strukturen und Zustände
Umgebung: A und B erfordern dieselbe Laufzeitumgebung/Hardware
Zeit: B muss existieren, solange A existiert
Kohäsion
Kopplung und Kohäsion
* Kohäsion: innerer Zusammenhang von Komponenten
Klasse beinhaltet Methode welche nicht zu den anderen gehört -> schwache Kohäsion
- Generell: Je stärker die Kohäsion, desto wohldefinierter ist die Komponente oder das Modul.
Kapselung und Information Hiding
- Kapselung:
Zugriff mittels Schnittstelle einschränken, System robuster gegenüber
Änderungen machen - Information Hiding:
Komponente ist “Black Box”, gibt keine Informationen über konkrete Implementierung
Teile und Herrsche
Modularisierung als wichtigstes technisches Hilfsmittel zur Reduktion der Komplexität einer Entwicklungsaufgabe.
- Große Aufgaben in Module einteilen um diese kleineren Einheiten realisieren zu können
- Am Ende werden Module wieder zu Gesamtaufgabe zusammengesetzt
Arten von Modularisierung:
* Funktionale Dekomposition (Zerlegen einer Aufgabe in Unteraufgaben)
* Strukturelle Dekomposition (Zerlegen von Systemkomponenten in
Teilkomponenten)
* Parametrisierung (Anpassung der modularen Stuktur an bestimmte
Bedürfnisse durch passende Konfiguration über Parameter)
Design by Contract
Idee: frühe Festlegung von Schnijstellen, die über den
Systemlebenszyklus weitgehend stabil gehalten werden.
Schnittstellenbeschreibung bildet “Vertrag” zwischen Nutzern und
ImplemenSerern einer Schnijstelle
- Nutzer verlässt sich auf das in der Schni_stelle spezifizierte Verhalten
- Implemen\erer garan\ert die Schni_stelle
Software-Wiederverwendung
Nutzung existierenden Wissens und existierender Softwareartefakte zur Entwicklung neuer Systeme
Optimierungsziele:
* Kostenreduktion und Verkürzung von Entwicklungszyklen (time-to-market)
* Qualitätssteigerung durch bewährte, getestete Komponenten (product quality)
* Senkung der Lebenszykluskosten (total cost of ownership)
Kompatibilität
Kompatibilität: Austauschbarkeit, Vereinbarkeit, Gleichwertigkeit
* Abwärtskompatibilität: ein (oh neueres) System erfüllt mindestens die
Anforderungen eines anderen (alten) Systems
* Aufwärtskompatibilität: ein altes System kann die Anforderungen eines
neuen Erfüllen
* AustauschkompaUbilität: eine Komponente ist durch eine andere
ersetzbar, ohne dass das Systemverhalten fehlerhah wird
* Interoperabilität: wechselseitige KompaSbilität, Komponenten passen
zusammen und können Seite and Seite eingesetzt werden
* KomposiUonskompatibilität: Schnijstellen von Komponenten passen
syntaktisch und semantisch zusammen
Austauschkompabilität
Eine Komponente B heißt austauschkompa@bel zu einer Komponente A, wenn man in einem beliebigen korrekten Programm bzw. einer korrekten Sobware A durch B ersetzt werden kann, ohne dass das Programm bzw. die Software inkorrekt wird.
Wiederverwendung und Wartung
- Bei Wiederverwendung ist im Allgemeinen die Wartung einfacher
- Wiederverwendete Komponenten müssen aber einer Qualitätssicherung
unterzogen und in Wartungsaktivitäten eingebzogen werden
Herausforderungen in der Wiederverwendung
- Hunderte von Entwurfsentscheidungen
- Komplexe Abhängigkeiten im Entwurf
- Mangelnde Dokumenta\on, insbesondere des Entwurfs
- Mangelde Transparenz des Entwurfs
- Fehlende Begründung der Entwicklungsschri_e und –entscheidungen
Wie kann man Probleme im Architekturentwurf verhindern?
Problemen begegnen durch:
* Entwicklerwissen dokumentieren (Abhängigkeiten und Entscheidungen)
* Standardlösungen beschreiben
* Lösungen bewerten
* Software dokumentieren (Entwurf und Implementierung)
* Wiederverwendung betreiben
* Terminologie konsolidieren (Glossar)
* Unternehmens-Know-How sichern
Strategien der Wiederverwendung
- Top-down (Aufbrechen von Aufgaben, bis gleichlautende Teilaufgaben
entstehen, für die Komponenten wiedervenwendet werden können) - Bottom-Up (Zusammensetzen des Systems aus vorhandenen
Komponenten) - Mischform ratsam (Zerlegung, sodass vorhandene Komponenten
eingebunden werden können)
++++
* Entwicklung mit Wiederverwendung (zunächst nicht geplant)
* Entwicklung für Wiederverwendung (von Beginn an vorgesehen)
Strategien der Wiederverwendung
Opportunistische (ad-hoc) vs. geplante (strategische) Wiederverwednung