Please enable JavaScript.

Coggle requires JavaScript to display documents.

Software-Architektur KE4 (Beschreibungstechniken für Architekturen (UML…

- - - - statische Sicht
        
        Klassendiagramm
        
        Struktur der Hauptabstraktionen eines Software-Systems, besonders die Beziehung zwischen Klassen und Typen im oo-Design.
        
        Beschreibt Typen u. Klassen der relevanten Objekte + Attribute u. Operationen der Klassen
        
        Beziehungen
        
        Assoziationen
        
        Generalisierung (Vererbung)
        
        Implementation Diagram
        
        Komponentendiagramm
        
        Struktur des Codes
        
        Deployment (Verteilungs) Diagram
        
        Konfiguration der Verarbeitungsknoten zur Laufzeit, dessen Verbindungen und die Komponenten, die darauf existieren.
        
        Zeigt Aspekte, die die Struktur der Softwarekomponenten betreffen (Quellcode + Implementierungsstruktur zur Laufzeit)
      - dynamische Sicht
        
        Anwendungsfalldiagramm
        
        Akteure u. Anwendungsfälle zusammen mit ihrer Beziehung
        
        Zustandsdiagramm
        
        Folgen von Zuständen u. Aktionen, die ein Element in seiner Lebenszeit durchlaufen kann (als Ergebnis von Reaktionen auf konkrete Events)
        
        hierarchische Zustandsmaschine
        
        Aktivitätsdiagramm
        
        Ablaufdiagramm
        
        dynamisches Verhalten von System(komponenten)
        
        Interaktionsdiagramm
        
        beschreibt Muster von Interaktionen zwischen Instanzen
        
        Sequenzdiagramm
        
        zeigt explizit Sequenzen von Impulsen
        
        geeignet für Echtzeit Spezifikationen u. komplexe Szenarien
        
        betont die zeitliche Reihenfolge der gesendeten Nachrichten während der Interaktion
        
        Kolloborationsdiagramm
        
        Zeigt Beziehungen zwischen und die Organisation der Instanzen
        
        Geeignet, um alle Effekte auf eine Instanz u. prozedurales Design zu verstehen
        
        zeigt Menge von Objekten, Verbindungen zwischen diesen u. Nachrichten die von diesen gesendet u. empfangen werden
    - - Zusammenspiel unterschiedlicher Notationen nicht klar definiert
      - kein grundlegendes Architekturmodell
      - unterstützt keine eindeutigen Abstraktionsmechanismen zwischen verschiedenen Beschreibungen
      - unterstützt keine Abstraktion für Kommunikation zwischen Komponenten
      - stellt keine Techniken für Parametrisierung bereit (Familie von Systemen)
  - - - Sammlung von Sprachen für die Architekturbeschreibung mit einer eindeutigen Semantik. Die Semantik sollte auch die Beziehung zwischen den Sprachen beschreiben.
      - Sammlung von Stilen, Regeln, Invarianten u. Eigenschaften, die die Verwendung der Sprachen regulieren
      - Definition der einzelnen Elemente einer Architekturbeschreibung
      - müssen genau definieren, was die Architektur des zusammengesetzten Systems ist
  - - - Architektonisches Element, das Interaktionen zwischen Komponenten und Regeln, die diese Interaktionen kontrollieren, modelliert.
      - Beschreibt komplexe dynamische Interaktionen zwischen Komponenten.
    - - Methodenaufrufe, gemeinsame Variablen, Protokolle zwischen Komponenten, Pipes, event broadcast
    - - Komponente übernimmt Verarbeitung, Konnektor beschreibt die Interaktionen zwischen Komponenten
  - - - richtiges Niveau der Abstraktion
      - standardisiert
      - basierend auf Techniken und Tools, die Konsistenzprüfunen, Visualisierung u. Codegenerierung erlauben
  - - - Komponenten- und Konnektortypen
        
        Komponententyp: Menge von ports u. component-specs
        
        jeder Port definiert einen logischen Interaktionspunkt zwischen der Komponente und ihrer Umgebung
        
        component-specs spezifizieren das abstrakte Verhalten der Komponente
        
        Konnektortyp: Menge von Regeln u. Klebespezifikation
        
        Die Rollen beschreiben das erwartete lokale Verhalten der interagierenden Beteiligten
        
        Klebespezifikation beschreibt, wie die Aktivitäten der Rollen koordiniert werden.
      - Menge von Komponenten- und Konnektorinstanzen
        
        tatsächliche Entitäten, die in der Konfiguration auftreten
      - Komponenten- u. Konnektorinstanzen werden kombiniert, indem definiert wird, welche Komponentenports mit welchen Konnektorrollen verbunden werden.
- - - - funktionale Anforderungen, die Ein. und Ausgabe und interaktives Verhalten des Systems beschreiben
      - Nicht-funktionale Anforderungen
      - technische Anforderungen, die z.B. vorschreiben welche Plattform oder welche Tools genutzt werden
      - Anforderungen des Management (Zeit, Kosten, ..)
    - - Die meisten Methoden beschreiben einen Prozess, in dem Komponenten und Konnektoren der architektonischen Strukturen bestimmt u. verfeinert werden.
      - Funktionales Design
        
        basiert hauptsächlich auf architektonischen Strukturen aus der statischen Sicht
        
        Architektur wird Menge von Modulen und deren Benutzungsbeziehungen betrachtet
        
        getrieben von funktionalen Anforderungen
      - Object-orientiertes Design
        
        Modellsprache UML unterstützt Beschreibung von verschiedenen statischen u. dynamischen Strukturen
        
        fokussiert sich auf Klassendiagramme, die die Vererbung und Verwendungsbeziehung ausdrücken.
        
        getrieben durch Identifizierung der wichtigen Objekte im System
      - Extreme Programming
        
        Softwareentwicklungsprozess, der die 4 Phasen integriert
        
        Grundidee: Prototypen erstellen, um schwierige technische und Design-Probleme zu lösen
        
        hebt Refactoring und das Hinzufügen von Funktionalität so spät wie möglich hervor
        
        eignet sich für Projekte mit wechselnden Anforderungen
    - - Einfluss von Softwarearchitektur auf Software Design
        
        Architektonische Strukturen werden verwendet, um das System auf verschiedenen Abstraktionsebenen zu zerlegen und um verschiedene Sichten auf das System zu erfassen, die sich auch verschiedenen Arten von Anforderungen beziehen.
        
        Unterstützt durch eine eindeutige Notationen
        
        Erlauben Raum für das Anwenden von Mustern und Standardlösungen
      - Architektonische Modelle, Strukturen, Aspekte, Muster u. Notationen spielen eine Rolle für die Designphase, die ähnlich der Rolle ist, die Programmiermodelle, -konzepte, -Muster u. -sprachen auf die Implementierungsphase ausüben.
  - - - Architektur sollte eindeutige Module besitzen, dessen Funktionalitäten den Prinzipien Datenkapselung u. Trennung von Verantwortlichkeiten entsprechen.
      - Trennung von Verantwortlichkeiten
      - Module mit Datenkaspelung sollten solche beinhalten, die die Eigenarten der Recheninfrastruktur kapseln
      - Architektur solle nie von einer bestimmten Version eines kommerziellen Produktes/Tools abhängig sein.
      - Bei parallel-verarbeitenden System, sollten die Architektur eindeutige Prozesse und Tasks definieren, die nicht unbedingt die Modulstruktur wiederspielen.
      - Die Architektur solle wenige, einfache Interaktionsmuster beinhalten. Die gleichen Dinge sollten auf die gleiche Art u. Weise gemacht werden.
    - - Bewertung anhand funktionaler u. technischer Anforderungen ist konzeptionell eher einfach, da das Ergebnis ja oder nein ist. (Ergebnis ist eindeutig)
      - Bewertung der nicht-funktionalen Anforderungen ist konzeptionell schwieriger, weil diese oft vage formuliert sind, Kompromisse zwischen konkurrierenden nicht-funktionalen Anforderungen unklar sind und es oft schwierig ist, die Auswirkung zu bestimmen, die die Architektur auf die nicht-funktionalen Anforderungen hat.