ppls

• Idee: Erstellung von Software durch Komposition von vorgefertigten, unabhängigen Software Komponenten
• (Zusammenbau von Systemen aus einzelnen Teilen)
• Ziel: Reduktion von Kosten und Zeit

• wird implementiert durch ein Objekt
• kann mehrere Interfaces besitzen
• weißt Abhängigkeiten aus

• besitzt eine Implementierung
• kann ein UI besitzen
• kann mehrere REST-Interfaces besitzen
• besitzt einen Datenhaushalt
• hat eine Laufzeitumgebung

• -Entwickler
• -Zusammensteller (zum Teil Endanwender)
  • Entwickelt Applikation durch (Wieder)verwendung von Komponenten
• System-Architekt
  • Setzt LFU für Komponenten auf
  • Einhaltung von Qualitätsanforderungen

Deployment ist wichtigste Eigenschaft einer Komponente!

Standardisiert Müssen standardisierten Komponentenmodell entsprechen; Vorgabe von Schnittstellen, Metadaten, Dokumentation, Zusammenstellungsart, Bereitstellung

Unabhängig Sollte ohne Abhängigkeiten auskommen; falls benötigt sollte die Abhängigkeit spezifiziert sein

Einsetzbar (deployable)Kann in LZU eingesetzt werden; liegen in Binärform vor; LZU baut auf OS auf

Dokumentiert Vollständig dokumentiert, damit Benutzer entscheiden können ob Ansprüche erfüllt sind; Beschreibung Syntax und Semantik

Zusammenstellbar Kann mit (mehreren) anderen zu höherwertigen Komposition zusammengestellt werden; Interaktion über öffentliche Schnittstellen

• Kapselung des Zustands
• Abstraktion
• Generalisierung und Spezialisierung
• Polymorphie

• Komponenten legen keine Datentypen fest
• Implementierung von Komponenten sind verschlossen
• Komponenten sind sprachunabhängig
• Komponenten sind standardisiert

Komponente:

• Binärform
• Wird in LZU deployed
• kann aus LZU entfernt werden
• Deployment während der Laufzeit

Objekt:

• Source Code
• Java: nur Kompolierung der Klasse, dann flexibles Einsetzen in Classpath möglich, keine Verlinkung

Commerciall Off-the-Shelf

• seriengefertigte Komponenten, gleichartig aufgebaut
• geringe bis gar keine Konfiguration
• vollständige Software-Lösung

• Rahmenwerk
• Definiert Software-Architektur
• Enthält Klassen, Bibliotheken und LZU
• nicht unmittelbar ausführbar, hohe Anpassung notwendig

Serverseitig und Clientseitig
 

• auf Application Server eingesetzt
• oft hohe Sicherheitsanforderungen
• Entwickler kann sich auf Geschäftslogik konzentieren
• Qualitätsanforderungen: hohe Skalierbarkeit, hohe Möglichkeit der Anpassung
• Transaktionsverarbeitung; Daten-Persistenz
• Bekannte Modelle: EJB, CORBA, .NET, OSGi

Thin-Client

• Darstellungs-Komponenten realisieren interaktive UI
• oft webbasiert
• Deployment auf Presentation Server; reine Darstellungs- und Interaktionslogik
• Bekannte Vertreter: Java Server Pages, Java Server Faces, AngularJS

Fat-Client

• ClientKomponenten realisieren interaktive UI; zum Teil mit Geschäftslogik
• Komponenten werden in Client-Umgebung eingesetzt
• Desktop-Anwendungen, Entwicklungsumgebungen
• Bekannte Vertreter: OSGi, JavaBeans, Active X, Adobe Flex, W3C Web Components, Rich Internet Applikation (RIA)

• required vs provided Interfaces
• operation vs port based
• drei Interface Levels zur Verifikation
• Kommunikation: Request-Response und Pipe & Filter

• Required Interface (Halbkreis)
  • Definiert Schnittstellen, welche die Komponente verwendet
  • Wird zur Laufzeit ausgelesen und übergeben (Dependency Injection)
  • Alternativ: aktive Einholung der Dependency
• Provided Interface (Lolipop)
  • Was wird bereitgestellt

• Operation-based
  • Schnittstelle wird durch Reihe von Operationen mit Eingabe- und Ausgabeparametern definiert
• Port-based
  • Ports sind Eintrittspujnkte für das Versenden und Empfangen von Daten
  • Anwendung: Verarbeiten von Sensor-Daten in eingebetteten Systemen
  •  

• Syntaktisch (Signatur des Interface, Datentypen)
• Semantisch (Werte innerhalb entsprechenden Rahmen)
• Verhalten (Angabe über Reihenfolge, wie Operationen aufgerufen werden)

• Request Response (bidirektional)
  • Sub-Varianten: Synchron vs Asynchron
• Pipe & Filter (unidirektional)
  • Koponenten sind Filter, welche Daten verarbeiten
  • Verbindungen sind die Pipes, welche Daten zur nächsten Komponente transportieren
  • Vor allem für datenfluss-basierte Architekturen

• JAR kann nicht ausdrücken, zu welchen JARs Abhängigkeit existiert
• zu viele JARs säumen Classpath
• Fehlende Abhängigkeiten erst zur Laufzeit bekannt
• Überdeckung (Shadowing) Typ-gleicher Klassen aus verschiedenen JARs

• Vertical Binding: Verbindung von zwei Interfaces vom gleichen Typ

• Horizontal Binding: Verbindung von Required und Provided Interface

• First-Party: Verbindung durch Entwickler

• Third-Party: wird vom Anwender verbunden

Exogenous

• explizite Verwendung von Konnektoren zur Interaktion zwischen Komponenten

Endogenous

• Binding ohne Konnektoren
• Binding, Interaktionsprotokolle und Fehlerhandling sind Bestandteil der Komponente

• Grundlegende Kommunikation zwischen Komponenten
• Konfiguration von einzelnen horizontalen Services (bspw. Datenbanken)
• Konfiguration von sicherheitstechnischen Einstellungen
• Konfiguration von Qualitätsanforderungen an die LZU
• Kontrolle des Lebenszyklus der eingesetzten Komponenten

• Dynamisches Deployment
• Definition von Bindungen
• Testen von Komponenten
• Status-Anzeige von Komponenten
• Konfiguration der LZU

1. Requirements Specification
2. Component Analysis
3. Requirements Modification
4. System Design with Reuse
5. Development and Integration
6. System Validation

• Requirements Specification
• Component Analysis:
  • Suche nach Komponenten, die (Teile) der Anforderungen erfüllen
  • meistens kein exakter Match möglich
• Requirments Modificatoion: Überarbeitung der Anforderungen; Berücksichtigung der gefundenen Komponenten
• System Design with Reuse: Entwicklung Software-Architektur; Berücksichtigung der gefunden Komponenten; Auswahl Komponentenmodell und LZU
• Development and Integration: Integration der Software-Komponenten (mit Entwicklung)

• In-House (Eigenentwicklung)
• Commercial off the shelf (vorgefertigt; kein Sourcecode)
• Open Source Components
• Outsource

1. Kontextsicht
2. Laufzeitsicht
3. Bausteinsicht
4. Verteilungssicht

• abstrakte Darstellung als Blackbox; logische Zusammenfassung von Systemen
• Schnittstellen werden nicht berücksichtigt, aber Abhängigkeiten
• Beim Datenfluss lediglich DTOs angeben (fachliche Sicht)

Umsetzung mit Paketdiagramm

• zeigen Ekemente des Systems, Subsystem, Komponenten, Klassen und deren Schnittstellen
• Darstellung von Abhängigkeiten

Nimmt etwa 60% der Architekturmodellierung in Anspruch

Komponenten-, Kompositionsstruktur-, Klassen-

• beschreibt Hardware-Komponenten (Server, Netzwerk, Firewall) mit beteiligten Protokollen
• Darstellung auch von LZU

Verteilungsdiagramm

• Welche Bestandteile des Systems zur Laufzeit existieren und wie diese zusammenwirken
• Modellierung von Boundary-Conditions: Systemstart, Shut-Down

• Modellbasierte Modellierung
• Architecture Description Language (ADL)
• Textuelle Architektur- Templates

• semi-formal (unpräzise, mehrdeutig)
• dient zur Kommunikation: Entwickler <-> Kunde
• UML

• Textuell, formal
• weniger Kommunikation, eher Umsetzung / Analyse
• ACME, Darwin, C2, PeerCAT

• freisprachliche Beschreibung der Architekturelemente
• keine formale Vorgaben
• wenige Standards (arc42)