Wiederholung Flashcards
Architekturziele
Architekturziele sind Qualitätsattribute, welche das System erreichen soll. Sie sind im Gegensatz zu Projektzielen meist langfristig.
Stammen häufig vom Architekten.
Beispiele: Wartbarkeit, Schönheit, Sicherheit, Performance, Stabilität, Qualitätsanforderungen
Rollenbild Architekt
Aufgaben des SW-Architekten
Architektur bewerten Mitarbeit bei Anforderungsmanagement Strukturen, Schnittstellen, Abhängigkeiten festlegen Übergreifende Konzepte klären Architektur kommunizieren Umsetzung begleiten und kontrollieren
Fokus auf Qualitätsmerkmale
Langlebigkeit
Wartbarkeit
Änderbarkeit
Robustheit
SW intensive Systeme
Informationssysteme - Entscheidungsunterstützungssysteme - Expertensysteme - Suchmaschinen - Büroautomatisierung Eingebettete Systeme - Software ist in Hardware eingebettet - Steuerung, Regelung, Überwachung, ... - Schwierige funktionale und nicht-funktionale Anforderungen Mobile Systeme - Semi-autonom - Verbindung nicht immer vorhanden
Fachliche vs. technische Architektur
Fachliche Architektur
- Funktionale Anforderungen
- Domänen Wissen
- werden zu:
- Fachliche Bausteine
- Fachklassen
- Datenbankschema
Technische Architektur
- Nicht-funktionale Anforderungen
- Übergreifende Konzepte
- SW Libraries, Plattform
- Hardware
- werden zu:
- Technische Schichten
- Server für Ausfallsicherheit
Fachliche Architektur wird in Stücke geschnitten, in vertikale Teile (Silos)
Technische Architektur wird in Scheiben geschnitten, horizontale Schichten. Jede Schicht stellt Schnittstellen bereit.
Systemabgrenzung
System - Ist von uns gestaltbar
Systemkontext - Hat Einfluss auf unser System, ist zum Verständnis wichtig.
Irrelevante Umgebung - Hat keinen Einfluss auf unser System und kann daher (explizit) ignoriert werden.
Fachlicher Systemkontext
Technischer Systemkontext
Use Case Diagramm
Komponentendiagramm
Randbedingungen
Eine Randbedingung ist eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.
Können nicht beeinflusst werden.
Werden nicht umgesetzt sondern schränken Umsetzungsmöglichkeiten ein.
Organisatorische Randbedingungen
- Organisation und Struktur
- Ressourcen
- Organisatorische Standards
- Juristisches
Technische Randbedingungen
- Hardware
- Software
- Betrieb
- Programmierung
Conways Law
Any organization that designs a system will produce a design whose structure is a copy of the organization
s communication structure.
Kräfte wirken in beide Richtung
- Teams werden auf Basis der Architektur aufgebaut
- Etablierte Organisationsstrukturen beeinflussen Denkweise und somit SW-Architektur
Definition “Architektur”
Besteht aus Strukturen Ist Abstraktion Beschreibt eine Lösung, welche selbst nicht die Lösung ist Basiert auf Entwurfsentscheidungen Ist Übergang von Analyse zur Realisierung Besteht aus verschiedenen Sichten Schafft Verständlichkeit Ist Rahmen für flexible Systeme Schafft Qualität
Software ist immateriell und komplexer
Prinzipien für gute Bausteine
Geheimnisprinzip und Kapselung (Information hiding)
Trennung von Verantwortlichkeiten (Single Responsibility-Principle, Separation von Concerns)
Hohe Kohäsion
Offen-Geschlossen-Prinzip (Open/Closed Principle)
Testbarkeit
Architekturebene
Business Sicht - Strategie - Business Architektur Vermittler - Unternehms-IT-Architketur IT-Sicht - SW-Architekturen -- hier ist der Architekt tätig - Infrastruktur-Architektur, HW-Architektur
Architektur eines Systems
Architekturentwurf
Top Down
- Start mit Vision vom Gesamtsystem
- Zerlegung in Teilprobleme
- Vorteile
- Gutes Verständnis
- Unabhängig von Technologie
- Kein Abgleiten in Details
- Sauber, konsistente Schnittstellen
- Entwurf im Ergebnis erkennbar
- Nachteile
- Übersehen von bereits existierenden Teillösungen
- Kritische Integration am Ende
- Spätes Feedback
- Viele ähnliche Lösungen in verschiedenen Projekten
Bottom-up
- Start mit wiederverwendeten Bausteinen
- Zusammenbau von Teillösungen
- Vorteile
- Hoher Wiederverwendungsgrad
- Beginn mit vermuteten Teilproblem
- Schrittweise Integration
- Frühe Tests möglich
- Nachteile
- Ev. nicht alle Teile System benötigt
- Fokus auf Technik statt Kundenwünschen
- Gefahr der frühzeitigen Optimierung
- Inkonsistentes Gesamtsystem
SOA
Komponenten bieten anderen Komponenten Dienste an
Kommunikation über Service Bus
Unabhängig von Plattform, Technologie, Anbieter
Registry, Bus, Adapter, Komponenten
Ableitung Fachlicherbausteine
Fachliche Bausteine aus Fachobjekten herleiten
- Leite aus Anforderungen Fachklassen her
- Gruppiere Fachklassen – ergibt fachliche Bausteine
Geeignet wenn Fachlogik ist komplex, umfangreich oder flexibl. Fachlogik wird in anderen Systemen wiederverwendet.
Fachliche Bausteine aus Benutzerinteraktionen herleiten
- Fasse in Bausteine alles zusammen was zur Interaktion mit einem Benutzer/Fremdsystem benötigt wird.
Geeignet wenn Fachlogik hauptsächlich aus Interaktionen mit Benutzern besteht. Datenzentrierte Fachlogik. Architekten und Entwickler verstehen Objektorientierung nicht.
Iterativer / Inkrementeller Entwurf
Gehe schrittweise vom Groben ins Feine
- Bausteine sollten geschachtelt sein Anzahl 7 +- 2
Probiere aus und gehe ggf. einen Schritt zurück
Betreibe regelmäßiges Recatoring
Bei nicht Umsetzung baut sich die technische Schuld immer weiter auf.
MDA
Modellgetriebene Architektur
Generierung von Anwendungen aus Modellen Ziele - Softwareentwicklung beschleunigen - Bessere Handhabbarkeit durch Abstraktion - Leichter Technologieumstieg
Automation durch Formalisierung
- Nicht 100% Automatisierung angestrebt
Vorgehen
PIM übersetzt in PSM übersetzt in CODE
PIM Plattformunabhängiges Modell
PSM Plattformspezifisches Modell
