Umfassendes Architekturmodell – Durchgängige Modellierung verschiedener

Aspekte eines Systems

Alexander Harhurin, Judith Thyssen12.01.2010

2

Agenda

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

Einführung: Architekturmodell

4

Von isolierten Lösungen zu einem durchgängigen Einsatz von Modellen

Domainagnostic

Domainappropriate

HighAbstraction

LowAbstraction

Domainagnostic

Domainappropriate

HighAbstraction

LowAbstraction

Situation Today Ideal Situation

Our mission

Systematik an Abstrakationsebenen/Architekturmodell als Leitfaden für einen durchgängigen Entwicklungsprozess

5

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 Ebenen3. Exemplarische domänen-spezifische Ausprägungen4. Prototypische Umsetzung in AF3

6

Software Development Perspectives

User Functionality Logical Architectuer Technical Architecture

Low details High details

Refinement Deployment

Akademisches Vorgehen:

7

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

8

Abstraktionsebenen-Systematik

9

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)

10

Dekompositionsebenen

Merkmale:• Schrittweise Dekomposition des Gesamtsystems in Subsysteme;• Relativer Systembegriff:

– Systemgrenze wechselt bei Übergang zwischen Dekompositionsebenen

– Subsystem bei Integrator = System bei Zulieferer• Dekompositonsebenen nicht a priori vorgegeben, sondern abhängig von Domäne,

Unternehmen, konkreten EntwicklungsgegenstandZiele:• 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

Gesamt- fahrzeug Sensorik Steuerung Aktuatoren

11

Dekompositionsebenen

Nutzungsperspektive (Funktionale Architektur)

13

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)

14

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?

SystemUmgebung Umgebung

15

Funktionshierarchie

Funktionshierarchie besteht aus• Atomaren Funktionen• Kombinierten Funktionen• Querbeziehungen

A

B C

D E F G

KH ML

AtomareFunktion

KombinierteFunktion

Querbeziehung

16

Funktion

• Formalisiert ein Szenario;• Gegeben durch

– eine syntaktische Schnittstelle und– eine (partielle) Abbildung von Eingaben auf Ausgaben

Funktionmi3,1 mi3,2 mi3,3 …

mi2,1 mi2,2 mi2,3 …

mi1,1 mi1,2 mi1,3 … i1

i2

i3

o1

o2

mo1,1 mo1,2 mo1,3 …

mo2,1 mo2,2 mo2,3 …

17

Funktion (2)

• Mögliche Notationstechniken:– I/O Automaten;– I/O Tabellen;– Sequenzdiagramme

idle active

cSpeed?x/mInstr!p(y,z)

rDistance?y/mInstr!p(y,z)cDistance?z/mInstr!

cSpeed?x/mInstr!

SysEnv

18

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.

19

Metamodell

20

Beispiel:ACC

ACC-steuerung

Tempomat Abstands-regelung

Stop&GoAbstandTempomat/KTempomat/G

Abstand/KAbstand/G

21

ACC: Funktionshierarchie

22

ACC: Funktionskombination

23

ACC: Funktionsspezifikation

24

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.

Logische Perspektive

26

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.

27

Netzwerk von Komponenten

• Besteht aus einer Familie von Komponenten, die über Kanäle untereinander und mit ihrer Umgebung verbunden sind.

• Gegeben durch – eine syntaktische Schnittstelle und– eine totale Abbildung von Eingaben auf Ausgaben

• Meist etablierte Notationstechnik: Komponentendiagramme und I/O Automaten

Communication Network

Sender ReceiverMedium

Medium

Network Manager

28

Modellierungstool AutoFocus

Struktur

Verhalten

Daten

… weitere Informationen unter http://af3.in.tum.de

http://af3.in.tum.de/images/e/e4/ExpandedDictionary.pnghttp://af3.in.tum.de/index.php/Image:IntListEvaluation.pnghttp://af3.in.tum.de/index.php/Image:Getting_Started_Tutorial_SSD_View.pnghttp://af3.in.tum.de/index.php/Image:Getting_Started_Tutorial_Root_State.png

29

ACC

30

ACC (2)

31

Component Hierarchy of ACC

ACC SystemACC System

PCSPCSACCACC

ACC On Off ConditionACC On Off ConditionACC CoreACC Core

ACC Core ConditionACC Core ConditionFollowUpFollowUpConstantSpeedConstantSpeed

DesiredSpeedDesiredSpeed SpeedControlSpeedControl DesiredDistanceDesiredDistance DistanceControlDistanceControl

32

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.

Technische Perspektive

34

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

35

ACC

36

ACC: Deployment

37

Generated Code

Geometrische Perspektive

39

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

Übergange zwischen Perspektiven

41

Zwei Dimensionen der Beschreibung

42

Ü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.

43

Zickzack-Vorgehen

44

Offene Fragen

• Wie werden Funktionen auf Komponenten abgebildet?– n:1

– n:m

• Wie werden Querbeziehungen abgebildet?

Analyse der Modelle

46

Formal Verification – Model Checking

• Properties for AutoFocus model• Export to SMV Model Checker

47

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

48

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

49

Test Case Generation and Execution

Test Case Generator

abstract test cases Test Drivertest case

specification

model of SUTexecutable test cases

apply to

Requirements

build

SUTdifferences in behavior?

50

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

Requirements

Env SUT

Test Cases

Implementation Model

generate

dv = vs – v;if (dv < 0) {decr();...

Code

generate

manualmanual

Test Model

test

51

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

52

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

53

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!

Zusammenfassung

55

Von isolierten Lösungen zu einem durchgängigen Einsatz von Modellen

Domainagnostic

Domainappropriate

HighAbstraction

LowAbstraction

Domainagnostic

Domainappropriate

HighAbstraction

LowAbstraction

Situation Today Ideal Situation

Our mission

Systematik an Abstrakationsebenen als Framework für einen durchgängigen Entwicklungsprozess

56

Model Repository

ArchitectureViews

ProductModel

MethodDefinition

Comprehensive Modeling Theory

Tooling Environment

Sem

antic

Dom

ain

Hol

istic

Arc

hite

ctur

alM

odel

Mod

elE

ngin

eerin

g E

nviro

nmen

tr

based on based on based on

part of refers to

developand analyze

materialize

processes

support

Umfassendes Architekturmodell – Durchgängige Modellierung verschiedener Aspekte eines SystemsAgendaEinführung: ArchitekturmodellVon isolierten Lösungen zu einem durchgängigen Einsatz von ModellenAbstraktionsebenen-Systematik – Zielsetzung Software Development PerspectivesProblemeAbstraktionsebenen-SystematikZwei Dimensionen der MatrixDekompositionsebenenDekompositionsebenenNutzungsperspektive (Funktionale Architektur)ZieleInhaltFunktionshierarchieFunktionFunktion (2)FunktionskombinationMetamodellBeispiel:ACCACC: FunktionshierarchieACC: FunktionskombinationACC: FunktionsspezifikationVorteile einer formalen SpezifikationLogische PerspektiveInhaltNetzwerk von KomponentenModellierungstool AutoFocusACCACC (2)Component Hierarchy of ACCBeitrag zur durchgängigen EntwicklungTechnische PerspektiveTechnische ArchitekturACCACC: DeploymentGenerated CodeGeometrische PerspektiveGeometrische PerspektiveÜbergange zwischen PerspektivenZwei Dimensionen der BeschreibungÜbergängeZickzack-VorgehenOffene FragenAnalyse der ModelleFormal Verification – Model CheckingFormal Specification – Example PropertiesACC: Model CheckingTest Case Generation and ExecutionTests from the Test ModelRandom Tests with Usage ProfileACC: Testing ResultsSummary: VerificationZusammenfassungVon isolierten Lösungen zu einem durchgängigen Einsatz von ModellenFoliennummer 56