download - SPES 2020

Umfassendes Architekturmodell –
Durchgängige Modellierung verschiedener
Aspekte eines Systems
Alexander Harhurin, Judith Thyssen
12.01.2010

Agenda
• Einführung: Architekturmodell
• Nutzungsperspektive
• Logische Perspektive
• Technische Perspektive
• Geometrische Perspektive
• Übergänge zwischen Perspektiven
• Zusammenfassung
2

Einführung: Architekturmodell

High
Abstraction
Low
Abstraction
Von isolierten Lösungen zu einem
durchgängigen Einsatz von Modellen
Situation Today Ideal Situation
Domain
agnostic
Domain
appropriate
Our mission
High
Abstraction
Low
Abstraction
Domain
agnostic
Systematik an Abstrakationsebenen/Architekturmodell als
Leitfaden für einen durchgängigen Entwicklungsprozess
Domain
appropriate
4

Abstraktionsebenen-Systematik –
Zielsetzung
• Zielsetzung:
– Bereitstellung einer grundlegende Systematik
für einen durchgängigen Entwicklungsprozess, die es erlaubt
• unterschiedliche Aspekte des zu entwickelnde System klar voneinander
getrennt zu modellieren und
• organisatorische Strukturen (Zulieferer/Integratoren-Beziehungen)
abzubilden.
• Geplantes Vorgehen:
1. Bereitstellung & Diskussion einer grundlegenden Systematik
2. Bereitstellung von fachliche Metamodelle, d.h. domänenübergreifende
Kern-Modellierungskonzepte für einzelnen Ebenen
3. Exemplarische domänen-spezifische Ausprägungen
4. Prototypische Umsetzung in AF3
5

Software Development Perspectives
Akademisches Vorgehen:
User Functionality Logical Architectuer Technical Architecture
Refinement Deployment
Low details High details
6

Probleme
• Ein umfangreiches System (Auto, Flugzeug) aus der Black-Box-
Sicht zu beschreiben ist unmöglich
• Man geht in der Praxis nicht strikt Top-Down vor:
– Bestimmte Teilsysteme existieren bereits
– HW-Topologie ist oft vorgegeben
– Ein größeres System wird zunächst nicht formal sondern „aus
Erfahrung“ in Teilsysteme unterteilt (Flugzeug besteht aus
Flügen, Cockpit, Kabine, etc.)
Lösungsvorschlag:
Zweidimensionale Systembeschreibung
7

Abstraktionsebenen-Systematik
8

Zwei Dimensionen der Matrix
• 1. Dimension: SW-Development Perspectives
– Getrennte Modellierung unterschiedlicher Aspekte des Systems
Komplexitätsreduktion
– Von abstrakten Funktionshierarchien bis zum deployten System inkl.
Geometrischer Anordnung
• 2. Dimension: Decomposition Layers
– Schrittweise Dekomposition und Modellierung des Gesamtsystems
– Erlaubt Abbildung organisatorischer Strukturen (arbeitsteiligen Prozess
mit Zulieferen/Integrator-Beziehung)
9

Dekompositionsebenen
Merkmale:
• Schrittweise Dekomposition des Gesamtsystems in Subsysteme;
• Relativer Systembegriff:
– Systemgrenze wechselt bei Übergang zwischen Dekompositionsebenen
Gesamt-
fahrzeug
Sensorik Steuerung Aktuatoren
– Subsystem bei Integrator = System bei Zulieferer
• Dekompositonsebenen nicht a priori vorgegeben, sondern abhängig von Domäne,
Unternehmen, konkreten Entwicklungsgegenstand
Ziele:
• Unterstützt arbeitsteiligen Prozess, bei dem Teilsysteme von Zulieferern entwickelt
werden;
• Ermöglicht Zickzack-Vorgehen:
– Anforderungen an das ganze System
– Erste logische Architektur
– Anforderungen an einzelne Teilsysteme
– Zerlegung der Teilsysteme in Komponenten
10

Dekompositionsebenen
11

Nutzungsperspektive (Funktionale
Architektur)

Ziele
• Modellierung des Systemverhaltens aus Sicht der Nutzer des
Systems (Blackbox-Sicht)
– Nutzer: menschliche Nutzer, umliegende Systeme, Sensorik/Aktorik,…
• Definition der Systemgrenze
– syntaktisches Interface,
– abstrakter Informationsaustausch
• Hierarchische Strukturierung der Gesamtfunktionalität aus Sicht der
System-Nutzer
• Formalisierung der funktionalen Anforderungen
– Bindeglied zwischen RE und Design
– Konsolidierung der funktionalen Anforderungen durch formale
Spezifikation und Analyse
– Erkennen und Modellieren von funktionalen Abhängigkeiten (Feature
Interaction)
13

Inhalt
• Funktionale Spezifikation ist eine Menge einzelner Szenarien;
• Ein Szenario ist ein zeitlicher Ablauf von Ein- und
Ausgabeereignissen;
• Black-Box-Sicht: Szenarien sind an der Systemgrenze sichtbar;
• Adressierte Fragenstellungen:
– Validierung: Entsprechen Szenarien den Anforderungen?
– Konsistenzprüfung: Gibt es Widersprüche in Anforderungen?
– Feature Interaction: Alle Wechselwirkungen berücksichtigt?
Umgebung System Umgebung
14

Funktionshierarchie
Funktionshierarchie besteht aus
• Atomaren Funktionen
• Kombinierten Funktionen
• Querbeziehungen
Querbeziehung
A
B C
D E F G
H K L M
Kombinierte
Funktion
Atomare
Funktion
15

Funktion
• Formalisiert ein Szenario;
• Gegeben durch
– eine syntaktische Schnittstelle und
– eine (partielle) Abbildung von Eingaben auf Ausgaben
m i1,1 m i1,2 m i1,3 … i1
m i2,1 m i2,2 m i2,3 …
m i3,1 m i3,2 m i3,3 …
i 2
i 3
Funktion
o 1
o 2
m o1,1 m o1,2 m o1,3 …
m o2,1 m o2,2 m o2,3 …
16

Funktion (2)
• Mögliche Notationstechniken:
cSpeed?x/mInstr!
– I/O Automaten;
– I/O Tabellen;
– Sequenzdiagramme
idle active
cDistance?z/mInstr!
cSpeed?x/mInstr!p(y,z)
rDistance?y/mInstr!p(y,z)
Env
Sys
17

Funktionskombination
• Parallele Komposition aller atomaren Funktionen;
• Unter Berücksichtigung von Querbeziehungen.
• Querbeziehungen sind domänenspezifisch;
• Beispiele:
– Priorität: Ein Interaktionsmuster hat Vorrang vor dem anderen;
– Reihenfolge: Ein Interaktionsmuster muss vor dem anderen
ausgeführt werden;
– XOR: Entweder eine oder die andere Funktion
– etc.
18

Metamodell
19

Beispiel:ACC
Tempomat
Tempomat/G
Tempomat/K
ACCsteuerung
Abstand/G
Abstand
Abstandsregelung
Abstand/K
Stop&Go
20

ACC: Funktionshierarchie
21

ACC: Funktionskombination
22

ACC: Funktionsspezifikation
23

Vorteile einer formalen Spezifikation
• Anforderungsmodell ist simulierbar validierbar;
• Automatisch analysierbar konsistent (widerspruchfrei);
• Generierung von Testfällen;
• Formale Basis für den Übergang zum Design:
– Mapping;
– Traceability;
– Verifikation;
• Formal aber handhabbar wegen Abstraktion von allen technischen
Details.
24

Logische Perspektive

Inhalt
• Übergang von der Problemdomäne zu der Lösungsdomäne
• White-Box-Sicht: die interne Struktur des Systems
• High-Level-Design: erster Schritt Richtung der Implementierung
• Struktur der Funktionalität unter Berücksichtigung von:
– Qualitätsmerkmalen (wie z.B. Modifizierbarkeit, Verfügbarkeit,
Sicherheit, Testbarkeit, etc.)
– Vorhandene HW-Topologie
– Organisationsstruktur
– Erfahrung
– etc.
26

Netzwerk von Komponenten
Communication Network
• Besteht aus einer Familie von Komponenten, die über Kanäle
untereinander und mit ihrer Umgebung verbunden sind.
• Gegeben durch
Sender Medium
Receiver
Medium
Network Manager
– eine syntaktische Schnittstelle und
– eine totale Abbildung von Eingaben auf Ausgaben
• Meist etablierte Notationstechnik:
Komponentendiagramme und I/O Automaten
27

Modellierungstool AutoFocus
Struktur
Verhalten
Daten
… weitere Informationen unter http://af3.in.tum.de
28

ACC
29

ACC (2)
30

Component Hierarchy of ACC
ACC
ACC Core
ConstantSpeed
ACC System
FollowUp
PCS
ACC On Off Condition
ACC Core Condition
DesiredSpeed SpeedControl DesiredDistance DistanceControl
31

Beitrag zur durchgängigen Entwicklung
• Wiederverwendung:
– Teilsysteme Bibliotheken
– Bibliotheken Teilsysteme
• Restrukturierung gemäß Qualitätsmerkmalen
• Traceability: Funktionale Anforderungen – Funktionen – logische
Komponenten
• Code-Generierung
• Deployment: logische Komponenten auf ECUs.
32

Technische Perspektive

Technische Architektur
• Beschreibung der Zielplattform, d.h. der HW-Topologie und der
Hauptcharakteristika der HW-Elemente
• Beschreibung der Sensorik, Aktorik und HMI
• Überprüfung von Echtzeiteigenschaften unter Berücksichtigung der
Zielplattform
34

ACC
35

ACC: Deployment
36

Generated Code
37

Geometrische Perspektive

Geometrische Perspektive
• Geometrische Anordnung der HW-Komponenten
• Überprüfung geometrischer Eigenschaften, z.B. sind redundant
ausgelegte Funktionen mindestens x Meter voneinander entfernt
• Für ZP-AP 1 steht die geometrische Sicht nicht im Vordergrund
39

Übergange zwischen Perspektiven

Zwei Dimensionen der Beschreibung
41

Übergänge
• Nutzungsperspektive Logische Perspektive
– N:1-Abbildung ist einfach
– N:M-Abbildung: laufende Arbeit
• Logische Perspektive Technische Perspektive
– Deployment
• Component Deployment (N:1-Abbildung der atomaren Komponenten)
• Port Deployment
– Code-Generierung
– Technische Architektur ist Architekturtreiber der Logischen Architektur
• Technische Perspektive Geometrische Perspektive:
– Deployment
– Geometrische Architektur ist ein Architekturtreiber der Logischen
Architektur.
42

Zickzack-Vorgehen
43

Offene Fragen
• Wie werden Funktionen auf Komponenten abgebildet?
– n:1
– n:m
• Wie werden Querbeziehungen abgebildet?
44

Analyse der Modelle

Formal Verification – Model Checking
• Properties for AutoFocus model
• Export to SMV Model Checker
46

Formal Specification – Example Properties
• OnOffArbiter
– Termination on brake (116)
– No non-zero acceleration when inactive:
• CoreArbiter
– Constant-Speed-Control Condition (122)
Absence of the check
whether driver brakes
in a transition
47

ACC: Model Checking
Results for the logical architecture of the ACC
– Approximately 20 properties formalised
– Three properties falsified and corresponding faults found
– All other properties proven correct
48

Test Case Generation and Execution
Requirements
build
model of SUT
test case
specification
Test Case
Generator
differences in behavior?
abstract
test cases
Test Driver
SUT
executable
test cases
apply to
49

Tests from the Test Model
• Real functional tests
faults which already reside in the
implementation model
different views on requirements
• Test model independently developed
• More abstract
Implementation
Model
generate
manual
Code
dv = vs – v;
if (dv < 0) {
decr();
...
Requirements
manual
Test Model
test
generate
Test Cases
Env SUT
50

Random Tests with Usage Profile
• New enhancement to our AutoFOCUS Test Generation Tool
• Individual Settings for every input port
– probability of NoVal
– probability distribution of values
– probability of value change
51

ACC: Testing Results
Generated 120 test cases each from system and test model:
– Generation takes only a few seconds
– in approx. 80% of test steps no error could be identified
– 3 differences between test model and system model identified (potential faults)
– 1 issue in test driver detected
– Most test cases reached one of these failure states after some time
52

Summary: Verification
Different kinds of errors were found:
• Testing:
– Several gaps in the specification identified
– Increased stability and robustness of the system
• Model Checking:
– Mainly implementation faults identified
A precise definition of the requirements and the system is key to an efficient verification!
53

Zusammenfassung

High
Abstraction
Low
Abstraction
Von isolierten Lösungen zu einem
durchgängigen Einsatz von Modellen
Situation Today Ideal Situation
Domain
agnostic
Domain
appropriate
Our mission
High
Abstraction
Low
Abstraction
Domain
agnostic
Systematik an Abstrakationsebenen als Framework für einen
durchgängigen Entwicklungsprozess
Domain
appropriate
55

Model
Engineering Environmentr
Holistic
Architectural Model
Semantic
Domain
Architecture
Views
develop
and analyze
part of
Tooling Environment
Model Repository
Product
Model
processes
materialize
refers to
based on based on based on
Comprehensive Modeling Theory
support
Method
Definition
56