Kapitel 10: Entwurf von Softwarearchitekturen IV - Vorlesung Softwarearchitektur| Wintersemester 2019/20 - Thorsten Weyer
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Vorlesung Softwarearchitektur| Wintersemester 2019/20
Kapitel 10: Entwurf von Softwarearchitekturen IV
Software-Produktlinienentwicklung | Variabilitätsmanagement
Thorsten Weyer
* die Folien dieser Vorlesungseinheit basieren auf der Vorlesung „Software-Produktlinien“ von Prof. Dr. Klaus Pohl an der Universität Duisburg-EssenLernziele
Die Studierenden
• können die Idee und die Vorteile der Software-Produktlinienentwicklung erläutern
• kennen die grundlegenden Begriffe in der Software-Produktlinienentwicklung (SPLE)
• können das SPLE-Rahmenwerk erläutern
• können die Prozesse der Domänen- und Applikationsentwicklung im SPLE erläutern
• können die Aspekte der Definition und Bindung von Variabilität im SPLE erläutern
• können Variabilität unter Verwendung des Orthogonalen Variabilitätsmodells modellieren
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 2Gliederung Idee und Vorteile der Software-Produktlinienentwicklung (SPLE) Grundlegende Begriff und Überblick über das SPLE Framework Domänen- und Applikationsentwicklung Modellierung von Variabilität und das Orthogonale Variabilitätsmodell Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 3
Software-Produktlinienentwicklung | Motivation
Zwei Arten der Individualisierung von Produkten:
(1) Individuelle software-intensive Systems
• Angepasst auf Basis individueller Kundenwünsche, z.B.
• Medizinische Informationssysteme
• Fahrzeuge
• CRM Systeme
• Buchhaltungssysteme
(2) Software-intensive Systeme für einen Massenmarkt
• Produktmanagement definiert Produktvarianten, z.B.
• Mobiltelefone
• Integrierte Entwicklungsumgebungen in verschiedenen Editionen
(Student, Standard, Professional)
Nicht auf individuelle Kundenwünsche angepasst!
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 4Software-Produktlinienentwicklung | Vorteile
• Kostenreduktion • Verkürzte Markeintrittszeit • Verbesserte Qualität
bis zu 60% bis zu 98% geringer bis zu 10-fach
• Verbesserte Produktivität • Fähigkeit in neue
bis zu 10-fach Märkte vorzudringen
Monate, nicht Jahre
• Geringerer
Personalaufwand
bis zu 87% verringert
Product Line Hall of Fame: http://splc.net/fame.html
> 20 Erfolgsgeschichten, u.a. Boeing, Bosch, HP, Nokia, Philips, Siemens, Toshiba
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 5Software-Produktlinien (SPL) und
Software-Produktlinienentwicklung (SPLE)
„A software product line is a set of software-intensive systems sharing a common,
managed set of features that specify the specific needs of a particular market segment or
mission and that are developed from a common set of core assets in a prescribed way.“
„Software product line engineering has proven to be the methodology for developing a
diversity of software products and software-intensive systems at lower costs, in shorter
time, and with higher quality.“
Quelle: Paul Clements; Linda Northrop: Software Product
Lines – Practices and Patterns. Addison-Wesley, 2002.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 6SPLE | Zwei Entwicklungsprozesse (1)
Domain
Domain Engineering Engineering
Der Prozess in der Software-Produktlinienentwicklung, in dem
Gemeinsamkeiten (commonalities) und Varianzen (variability) Domain Artifacts
der Produktlinie definiert und realisiert werden.
1. Definiere Gemeinsamkeiten und Varianzen
• Welche Aspekte haben alle Applikationen der Produktlinie gemein? Gemeinsamkeiten
• Wie können sich die Applikationen der Produktlinie unterscheiden Varianzen
• Gemeinsamkeiten und Varianzen definieren den Scope der Produktlinie
2. Entwicklung wiederverwendbarer Domänenartefakte, die Variabilität inkludieren
- Definition der Produktlinien-Plattform
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 7SPLE | Zwei Entwicklungsprozesse (2)
Application Engineering
Der Prozess in der Software-Produktlinienentwicklung, in dem die
Applikationen der Produktlinie durch die Wiederverwendung von
Domänenartefakten und Bindung der Variabilität konstruiert werden.
1. Definiere die Bindung der Variabilität
für individuelle Applikationen
2. Ableitung von Applikationen der Produktlinie
durch Wiederverwendung von Domänenartefakten
• d.h., binden der Variabilität in den Domänenartefakten
durch kontrollierte Erweiterung, Veränderung, Konfiguration der
Domänenartefakte
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 8Wirtschaftlicher Hintergrund | Grenznutzen
Break Even Point (BEP)
Akkumulierte
Kosten
Einzelsystementwicklung
Software-Produktlinienentwicklung
Geringere Kosten
Vorabinvestitionen pro System
Anzahl unterschiedlicher Systeme
Beachte: zeigt erwarteten Vorteil (basiert nicht auf empirischen Daten)
Abgesicherte empirische Erkenntnisse: Break-Even bei 3-4 Applikationen
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 9Wirtschaftlicher Hintergrund | Markteintrittszeit
Idealisiert
Einzelsystementwicklung
Time to SPLE (Inkrementelle Einführung)
Market SPLE („Big Bang“)
durch Wiederverwendung verkürzte Entwicklungszyklen
Zeit zur Konstruktion
wiederverwendbarer
Artefakte
Anzahl unterschiedlicher Systeme
Abbildung zeigt den erwarteten Einfluss (basiert nicht auf empirischen Daten)
Tatsächliche Einfluss basiert auf der Einführungsstrategie!
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 10Wirtschaftlicher Hintergrund | Produktqualität
• Entwicklungsartefakte werden mehrfach in verschiedenen Applikation
wiederverwendet.
• Konsequenz:
• Höhere Wahrscheinlichkeit Fehler aufzudecken
• Rechtfertigt einen höheren Qualitätssicherung- bzw. Testaufwand
• Jede PL-Applikation partizipiert an identifizierten und korrigierten Fehler
Das heißt, jede Produktlinien-Applikation …
… trägt zur übergeordneten Qualität der Produktlinie bei
… partizipiert an der verbesserten Qualität der Produktlinie
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 11Gemeinsamkeiten (Commonalities)
„ […] Menge von Annahmen, die für alle Applikationen der Produktlinie gültig sind“
Synonym: Invariante
Navigation System Professional Navigation System Professional + Apps
© BMW
• 8,8“ Display • Integration of Apple iPhone
• 20 GB Storage (Music) Applications
• No iPhone Integration • Facebook, Twitter …
Commonality: Screen and Navigation System
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 12Software-Produktlinienentwicklung | Begriffe:
Variationspunkt, Varianten, …
Modellierung der Software-Produktlinienvariabilität
OVM VP
Routen-
führung
[1..2]
Beziehung VP
V V
VP
Sprache Bildschirm
zu Artefakten Bluetooth
Bildschirm-
auflösung
[1..1]
[1..1]
V V V
V V
320x240 640x480 800x600
Version 1.1 Version 2.0
Domänenartefakte Was variiert? Variabilitätssubjekt Variationspunkt
Anforderungsspezifikationen, Wie variiert es? Variabilitätsobjekt Varianten
Architekturspezifikation, Testfälle,
Produktstrategie, Wie ist die Varibilität eingeschänkt? Variabilitätsabhängigkeiten
Unternehmensleitbild, … Warum variiert es? Nachvollziehbarkeitsbeziehungen
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 13Software-Produktlinienentwicklung |
SPLE Framework (Überblick)
Engineering
Domain
Engineering
Application
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 14Software-Produktlinienentwicklung |
Wiederverwendung von Entwurfswissen
Wiederverwendung von
Entwurfskonzepte, Entwurfswissen
z.B. Architekturtaktiken
Engineering
(Plattform)
Domain
Domäenarchitektur
(Plattformarchitektur)
Domänenanforderungen
- Funktionalität
- Qualität
- Randbedingungen
Engineering
Application
Entwurfskonzepte,
z.B. Architekturtaktiken
Applikationsarchitektur
(Applikation)
Applikationsanforderungen:
- Funktionalität
- Qualität
- Randbedingungen
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 15Domain Engineering | Aktivitäten
Domain Design
Entwicklung der Produktlinienarchitektur (auf Basis von Entwurfskonzepten
verschiedener Granularitätsstufen, z.B. Architekturstile -/muster, Referenzarchitekturen,
Architekturtaktiken)
Zuordnung der Variabilität in den Anforderungen zur Architektur (z.B. zu
Architekturelementen)
Definition der zusätzlich notwendigen Variabilität (meist technische Variabilität)
Integration von Mechanismen zur Bindung der Variabilität
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 16Abbildung der Variabilität (1)
Variabilität in den Anforderungen
enter PIN swipe magnetic
card
touch fingerprint
door lock Ist typischerweise eine
scanner
authentication m:n-Beziehung
Variabilität in der Architektur
«component» «component»
«component»
Fingerprint Magnetic Card
Keypad
Scanner Reader
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 17Abbildung der Variabilität (2)
Variabilität in der Architektur
«component» «component»
«component»
Fingerprint Magnetic Card
Keypad
Scanner Reader
Ist typischerweise eine
m:n-Beziehung
Variabilität in der Realisierung (Code)
class Keypad { class Magnetic class Fingerprint
/* … */ CardReader { Scanner {
} /* … */ /* … */
} }
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 18Application Engineering | Zwei zentrale Schritte
1. Definieren der Bindung
• Spezifikation, in welcher Weise die Variabilität in der Produktlinie gebunden
wird, d.h. welche Varianten werden gewählt.
2. Durchführen der Bindung
• Erweiterung / Modifikation / Konfiguration der Domänenartefakte anhand der
definierten Bindungen
• Als Ergebnis ist die Variabilität der Produktlinie in den abgeleiteten Artefakten
des Application Engineering und im resultierenden Softwaresystem nicht mehr
vorhanden.
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 19Definition und Durchführung der Bindung
Definition der Bindung Durchführung der Bindung
Die Definition der Bindung kann in jeder Die Durchführung der Bindung der
„Phase“ des Application Engineering Variabilität kann zu verschiedenen
Prozesses stattfinden: Zeitpunkten geschehen:
• Requirements Engineering • Im Vorfeld der Kompilierung
• Entwurf • Zur Kompilierungszeit
• Realisierung • Zur Verlinkungszeit
• Test • Zur Ladezeit
• Laufzeit / Betrieb • Zum Start der Applikation
• Im Betrieb
Merke: Definition und Durchführung von Bindungen zur Laufzeit führt zum Konzept
der Dynamischen Produktlinien! Oft eingesetzt zur Realisierung Adaptiver Systeme!
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 20Bindung der Variabilität einer Produktlinie |
Unabhängigkeit von Definition und Durchführung
ISDN c.c. Autorisierung wurde in der Realisierung
Durchführen der Bindung definiert + realisiert durch das Laden spezifischen
Codes währen des Starts
„Enterprise Edition“ wurde im RE festgelegt
+ realisiert während der Laufzeit durch
Laufzeit Eingabe eines Aktivierungs-Codes X
X
Startzeit Authentifikation via Fingerabdruck
wurde während des RE festgelegt X
+ realisiert durch
Ladezeit Transformation von UML Modellen Alternative Systemfunktionen werden aufgrund
einer Kontextveränderung aktiviert
(Adaptives System – Dynamische SPL)
Link-Zeit X
LAN wurde für das Home Automation System zur
Kompilierungszeit Entwurfszeit ausgewählt + realisiert durch die Verlinkung spezifischer
Bibliotheken
X
vor Kompilierung
Requirements Design Realisierung Test Betrieb … Definition der Bindung
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 21Modellierung der Variabilität von Produktlinien |
Integrierte Modellierung
Architekturentwurf: Definition von Varianten und Variationspunkten mit Hilfe von Stereotypen
Gemeinsamkeiten Variabilität
* 1 «VariationPoint»
File
File Type
Binary ASCII «Variant» «Variant» «Variant»
File File MP3 WMF PDF
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 22Modellierung der Variabilität von Produktlinien |
Herausforderungen
Class Diagram
* 1 «VariationPoint»
File
File Type
Which “variants”
Welche«variants»
Variantenare
are
sindrelated?
related?
relationiert?
Binary ASCII «Variant» «Variant» «Variant»
File File MP3 WMF PDF
Use Cases Test Case Scenarios
«Variant» :Media Player
: User
display PDF
document «Variant» open document
«Variant»
«Variant» play MP3
play MP3 audio
provide media
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 23Modellierung der Variabilität von Produktlinien |
Dediziertes Modell
1. Trennung der Variabilitätsinformationen der
PL von den Entwicklungsmodellen
• Variabilitätsmodelle umfassen:
• Variationspunkte Variabilitätsmodell
• Varianten Variabilität der Produktlinie ist im
• Constraints Variabilitätsmodell dokumentiert
• Begründungen
• Basismodelle: Konventionelle Entwicklungsmodelle
werden als Basismodelle bezeichnet:
• Kontextmodelle
• Use-Case-Modell
Basismodelle
• Architekturmodelle
Basismodelle beinhalten
• Implementierung
gemeinsame und variable Aspekte
Orthogonal Variability Modelling (OVM) („150% Modelle“)
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 24Orthogonale Variabilitätsmodellierung (OVM)
Beispiel Variationspunkt
Variabilitätsmodell
VP
Constraint
File
Type
2..3
V V V
Variante
PDF WMF MP3
Komplexität der Modell wird reduziert Definition von Variabilitäts-Constraints
Variabilitätsmodelle bilden lediglich die Variabilitäts-Constraints werden an einer Stelle
Variabilitätsinformationen der PL ab modelliert und sind nicht über Basismodelle hinweg
(“Trennung der Belange”) verteilt
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 25Modellierung der Variabilität von Produktlinien |
Beziehungen der Variabilität zu Basismodellen
2. Variabilitätsinformationen, die in den Variabilitätsmodellen
dokumentiert sind, werden mit solchen Basismodellen (bzw.
Teilmodellen, einzelnen Elementen) in Beziehung gesetzt, die von der
Variabilität betroffen sind Variabilitätsmodell
Voraussetzung: Definition von Typen von Trace-Beziehungen und
Dokumentation von Trace-Beziehungen
Von: Variationspunkten und Varianten
Zu: zugehörigen Artefakten der Basismodellen Basismodelle
Merke: Trace-Beziehungen (d.h. inhaltliche Beziehungen zwischen Variabilitätsmodellen und Basismodellen)
können mit Hilfe von Werkzeugen erstellt und verwaltet werden (auch: Automatisierte Trace-Analyse)
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 26Orthogonale Variabilitätsmodellierung (OVM)
| Vorteil ein „Zentrales Modell“
Modell der Architekturentwurf
VP
PL Variabilität
File AVI
Variabilitäts- Type
informationen sind
nicht über V V
MP3
verschiedene Artefakte MP3 PDF PDF
verteilt
die Variabilität der Test Case Szenarien
Produktlinie ist nicht
Use Cases
über die verschiedenen : User
:Media Player
Basismodelle hinweg display PDF
open document
definiert, sondern in document
einem kohärenten play MP3
Modell play MP3 audio
provide media
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 27Orthogonale Variabilitätsmodellierung|
Fortgeschrittene Modellierungskonstrukte (Bsp.)
• Variabilitätsabhängigkeit “Optional”
• Diese Varianten können, müssen aber nicht Variation Point Variant
notwendigerweise, zu dem Variationspunkt
gebunden werden Variability
Dependency
• Variabilitätsabhängigkeit “Mandatory”
{complete, disjoint}
• Diese Varianten muss zu einem Variationspunkt
gebunden werden, wenn der Variationspunkt Optional Mandatory
berücksichtigt wird.
Beispiel VP
OVM Meta-Model
User
Interface Notation
V V V
Web
Wall Panel App
Interface
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 28Orthogonale Variabilitätsmodellierung|
Fortgeschrittene Modellierungskonstrukte (Bsp.)
• Auswahl von Alternativen
Gruppiert eine Menge optionale Variabilitätsabhängigkeiten
min..max definiert die erlaubte Anzahl von Varianten, die Variability
gebunden werden können Dependency
Default ist 1..1; unbound max = * {complete, disjoint}
Alternative
Choice 0..1 part of 2..*
VP min
Optional Mandatory
Beispiel
max
Tuner
1..3 Notation
V V V
min..max
Satellite Terrestrial Cable
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 29Orthogonale Variabilitätsmodellierung|
Fortgeschrittene Modellierungskonstrukte (Bsp.)
• Die Selektion einer Variante macht die Selektion einer anderen Varianten notwendig
(requires) unidirektionale Abhängigkeit (hier: Implikation)
• Beispiel: Die Aufnahmefunktion für TV-Sendungen setzt eine interne Festplatte voraus
VP VP
Premium Storage
functions
V V V
V V
Internal External Network
Front TV Show
Hard Disk Hard Disk Storage
Display Recording
requires
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 30Orthogonale Variabilitätsmodellierung|
Fortgeschrittene Modellierungskonstrukte (Bsp.)
Typen von “Requires”-Beziehungen requires
VP VP
auch: vp verlangt vp
VP1 VP2 VP VP
VP1 VP2
V V V V 1..2
requires V V V V
V1.1 V1.2 V2.1 V2.2
auch: v verlangt v V1.1 V1.2 V2.1 V2.2
VP VP
VP1 VP2 VP VP
VP1 VP2
V V V V
V V V V
V1.1 V1.2 V2.1 V2.2 V1.1 V2.1 V2.2
V1.2
auch: v verlangt vp
auch: vp verlangt v
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 31Orthogonale Variabilitätsmodellierung|
Fortgeschrittene Modellierungskonstrukte (Bsp.)
• Die Selektion einer Variation führt zum Ausschluss einer anderen
Variante excludes (mutex) bidirektionale Abhängigkeit
• Beispiel:
Merke: Abhängigkeiten vom
• Selektion von “convertible” als Fahrzeugtyp führt zu einem Typ „exclude“ können
Ausschluss der Variante “sunroof” und umgekehrt! definiert werden zwischen:
VP 1) Varianten; 2) Varianten
VP und Variationspunkten; 3)
Extras
Variationspunkten
Chassis
(siehe OVM Meta model)
1..1
…
V auch: v schließt aus vp
V V Sunroof v schließt aus v
V
vp schließt aus vp
StationWagon Sedan Convertible
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 32Orthogonale Variabilitätsmodellierung|
Beziehungen zu Basismodellen
Erweiterung des OVM Meta model: Artefaktabhängigkeit (Artifact dependency)
• Trace-Beziehungen setzen Varianten mit Basismodell-Artefakten in Beziehung
1..1
Variation Point Variant
1..*
“Notation”
0..*
realized by
Artifact
Dependency
1..*
Development
Artifact
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 33Orthogonale Variabilitätsmodellierung|
Beziehungen zu Basismodellen (Beispiel)
Variability Model
VP
Comfort
variants
V Anti-theft V
Heat shield
protection
Component Control
Activate heat shield!
Activate anti-theft protection!
Activate tinting!
Heat
Tinting Tinting Anti-theft
shield
off on mode
Deactivate tinting! mode
Deactivate anti-theft protection!
Deactivate heat shield!
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 34Orthogonale Variabilitätsmodellierung|
Beziehungen zu Basismodellen (Beispiel)
Variability Model
VP
Comfort
variants
V Anti-theft V
Heat shield
protection
Component Control
Activate heat shield!
Activate anti-theft protection!
Activate tinting!
Heat
Tinting Tinting Anti-theft
shield
off on mode
Deactivate tinting! mode
Deactivate anti-theft protection!
Deactivate heat shield!
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 35Orthogonale Variabilitätsmodellierung|
Beziehungen zu Basismodellen (Beispiel)
Variability Model
VP
Comfort
variants
V Anti-theft V
Heat shield
protection
Component Control
Activate heat shield!
Activate anti-theft protection!
Activate tinting!
Heat
Tinting Tinting Anti-theft
shield
off on mode
Deactivate tinting! mode
Deactivate anti-theft protection!
Deactivate heat shield!
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 36Orthogonale Variabilitätsmodellierung|
Beziehungen zu Basismodellen (Beispiel)
Variability Model
bMSC „Activate anti -theft protection“
VP
Control Light Sensor Window Control
Comfort
variants
Tinting off Sensor deactivated No tint
V V
Anti-theft
Heat shield
protection Activate anti-theft protection
Variable hMSC Dynamic Window Tinting Windows
Anti-theft mode
opaque
Activate anti- Activate automatic Activate bMSC „Deactivate anti -theft protection“
theft protection tinting heat shield
Control Light Sensor Window Control
Sensor deactivated Windows
Tint window Tint window Anti-theft mode
opaque
Deactivate anti-theft protection
Brighten window Brighten window
Tinting off No tint
Deactivate
Deactivate anti- Deactivate Deactivate
automatic tinting
theft protection automatic tinting heat shield
with tinted window
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 37Orthogonale Variabilitätsmodellierung|
Vergleich mit Feature-Modellierung (Überblick)
Orthogonales Variabilitätsmodell Feature Diagramm
Navi
Bluetooth Bildschirmauflösung
VP
VP
VP
1..1 1..1
Bildschirm-
Bluetooth auflösung
[1..1]
[1..1]
V V V
V V
320x240 640x480 800x600 Version 1.1 Version 2.0 320x240 640x480 800x600
Version 1.1 Version 2.0
• Ähnliche Ausdrucksmächtigkeit Arten von Featuremodellen (Beispiele)
• Basic feature models
• OVM dokumentiert nur PL Variabilität • mandatory, alternative and ‘or’ features
• ‘requires’ and ‘excludes’ cross-tree
constraints
• OVM unterscheidet Variationspunkte und Varianten • Extended feature models
• In addition: arbitrary feature
• Feature-Modelle haben eine explizite hierarchische Struktur attributes; e.g., to express
variation in quality requirements
• Cardinality-based feature models
• In addition: UML-like multiplicities [m..n] for
feature selection, and instantiation
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 38Zusammenfassung • Die Software-Produktlinienentwicklung ist ein mächtiger Ansatz zur Wiederverwendung von Architekturwissen (allg. von Entwicklungswissen). • Geplante (proaktive) Wiederverwendung, die mit gewissem Aufwand im Vorfeld einhergeht. • Zwei zentrale Prozesse: Domain Engineering und Application Engineering. • Domain Engineering: Realisierung der wiederverwendbaren Artefakte inkl. Variabilität ( Plattform). • Application Engineering: Definition von Applikationen / Systemen auf Basis der Plattform durch binden von Variabilität. • Dokumentation der Variabilität durch Variabilitätsmodelle hat wesentliche Vorteile ggü. der integrierten Modellierung von Variabilität. • Zentrale Konzepte zur Modellierung der Variabilität einer Software-Produktlinie sind Variationspunkt (Was variiert?), Variante (Wie variiert es?), Variabilitätsabhängigkeiten und Artefaktbeziehungen zu den typischen Entwicklungsartefakten. • Orthogonales Variabilitätsmodell ist ein bekannter Ansatz zur Variabilitätsmodellierung, der sich im Detail von Ansätzen zur Feature-Modellierung unterscheidet, weil nur die Variabilität der Produktlinie modelliert wird und explizit zwischen Variabilitätssubjekt und Variabilitätsobjekt unterschieden wird. Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 39
Werkzeugunterstützung (OVM-gestützte
modellbasierte Softwareproduktlinienentwicklung)
Zum Beispiel: PTC Integrity Modeler
Quelle: David Norfolk: PTC Integrity Modeler – a standards-based tool
for Systems and Software Engineering
Vorlesung: Softwarearchitektur | WS 2019/20 Universität Koblenz-Landau | Institut für Informatik | Thorsten Weyer 40Sie können auch lesen
