Modellierung in der Software- und Systementwicklung

Modellierung in der 

System- und Softwareentwicklung: 

Theorie und Praxis 

Von den Anforderungen zur Architektur 

Manfred Broy 

Lehrstuhl für Software & Systems Engineering 

Technische Universität München 

Institut für Informatik 

Über die Natur der Softwareentwicklung 

Zwei extreme Sichten: 

• Softwareentwicklung bedeutet die Konstruktion eines formalen, 

mathematischen, logischen Modells, das effizient ausführbar ist - ist 

also eine ziel- und zweckgerichtete Formalisierung 

! Software ist ein mathematisches Objekt, quantifizier-, spezifizier- und 

verifizierbar 

• Softwareentwicklung ist Kunst und Handwerk; sie basiert auf 

Erfahrung, Augenmaß und Können 

! Software definiert sich durch die Ausführung auf einer 

Hardware/Softwareplattform, ist von Natur aus unzuverlässig, ad hoc, 

wird in Versuch und Irrtum erstellt 

Festkolloquium, Hans-Dieter Ehrich, Februar 2007 

Manfred Broy 2

Was ist ein Modell? 

Ein Modell ist 

• eine Abstraktion 

• bezogen auf einen Betrachtungsgegenstand 

• unter einem Gesichtspunkt für einem bestimmten Zweck. 

Ein Modell erfordert eine Präsentationsform durch 

• eine Metapher (Gedankenmodell) durch Text 

• eine Sprache (Programmiersprache, Modellierungssprache) oder 

• einen Gegenstand. 

Ein Modell erlaubt bestimmte Aussagen über den Betrachtungsgegenstand. 

Ein Modell dient 

• der Kommunikation zwischen Menschen 

• aber auch der Automatisierung 

Daraus ergibt sich die Qualität eines Modells 


Manfred Broy 3 

Zwei essentielle Aspekte der Software Entwicklung 

Software Entwicklung bedeutet immer: 

+ Formalisierung: Software ist formales Artefakt 

+ Modellierung: Software bedeutet immer Abstraktion von der 

Wirklichkeit (von dem Betrachtungsgegenstand) und damit 

Modellbildung 

Jedes Softwaresystem enthält zwangsläufig Modelle und zwar 

• ein Domänenmodell (fachliche Gesichtspunkte) 

• ein Modellierung technischer Gesichtspunkt 

Beispiele: 

• Die „Blutgruppen der Komponenten einer Softwarearchitektur“ a la 

Siedersleben 

• Das R3 System von SAP 

Interessante Frage: Welche der Modelle sind wertvoller? 


Manfred Broy 4

Modelle im Code 

Im Code von Softwaresystemen (= Programme + Daten) 

sind 

• das Domänenmodell (fachliche Gesichtspunkte) 

• die Modellierung technischer Gesichtspunkt 

„vergraben“ (sind implizit). 

• Beim Entwickeln und Warten von Software müssen diese 

Modelle ständige genutzt (und gegebenenfalls 

wiederentdeckt werden) 



Ein Beispiel: Das Problem der absoluten Mehrheit 

totale Funktion f: IN ! Partei 

Anzahl n " IN, mit n > 0 von Parteigängern. 

#(p, k) = | {i " IN: 1 ! i ! k # f(i) = a} | 

major(p, k) = 2 * #(p, k) > k 

anarchic(k) = $ p " Partei: 2 * #(p, k) " k 

A, H : Var Set Nat 

Wir wählen als Invariante 

A anarchisch 

H homogen: $ m " H: f(m) = r 

e = |H| 

k, e : Var Nat, r : Var Partei 

k, r, e := 2, f(1), 1; 

do k ! n then 

if f(k) = r then k, e := k+1, e+1 

[] f(k) % r # e = 0 then k, r, e := k+1, f(k), e+1 

[] f(k) % r # e > 0 then k, e := k+1, e–1 

H, A := {1}, Ø 

H := H ' {k} 

H := {k} 

H, A := H\{any(H)}, A'{k, any(H)} 

fi od 

{¬anarchic(n) & major(r, n)} 

A anarchisch # H homogen # A'H = {1, ... n} 


Manfred Broy 6

Und noch ein Beispiel 

SPEC SEQ = 

{ 

based_on BOOL, 

sort Seq (, 

‹› : Seq (, 

‹_› : ( ! Seq (, Mixfix 

_°_ : Seq (, Seq ( ! Seq (, Infix 

ises : Seq ( ! Bool, 

first, last : Seq ( ! (, 

head, rest : Seq ( ! Seq (, 

Seq ( generated_by ‹›, ‹_›, _°_, 

ises(‹›) = true, 

ises(‹a›) = false, 

ises(x°y) = and(ises(x), ises(y)) , 

x°‹› = x = ‹›°x, 

(x°y)°z = x°(y°z) , 

first(‹a›°x) = a, 

last(x°‹a›) = a, 

head(x°‹a›) = x, 

rest(‹a›°x) = x 

} 

Hier haben wir alles perfekt: Klare Modelvorstellung, Syntax, logische Theorie 



Ein formales Modell umfaßt: 

• Syntax 

! Formale Sprache 

! Graphik 

Formale Modelle 

• Semantik - Festlegung der Bedeutung 

! Informell 

! Formal 

• Theorie 

• Denotationell 

• Axiomatisch 

• Operationell 

! Theoreme 

! Umformungsregeln 


Manfred Broy 8

“Formal Methoden” und “Software Engineering” 

• Formal Methoden werden häufig als inadäquat, zu teuer, 

unrealistisch, nicht auf grosse Systeme unwendbar 

beurteilt 

• Praktische Software Entwicklung wird often als “ad hoc”, 

“immature”, uncontrollable, und “not an engineering 

discipline” bewertet 



Digitale Modellierung 

Die Modelle der Informatik sind digital! 


Manfred Broy 10

Essentielle Beiträge der Modellorientierung 

• Software ist unanschaulich („immateriell“), bestimmt komplexe 

dynamische Vorgänge 

! Software wird durch Modelle begreifbar 

• Die Ausführungsmodelle unserer Maschinen sind undurchsichtig 

! Software wird von den komplexen („low level“) Ausführungsmodellen 

unabhängig 

• Software ist umfangreich und unübersichtlich 

! Modelle erlauben gezielte Darstellungen von Eigenschaften 

! Modelle geben Übersicht 

• Software braucht unterschiedliche Darstellung verschiedener 

Aspekte 

! Modelle können auf Aspekte zugeschnitten werden - 

Sichtenmodellierung 

• Software braucht präzise Analysen 

! Modelle können auf geeignete Theorien abgestützt werden 

! Modelle erlauben tiefe Automatisierung/Werkzeugunterstützung 



Modellierung in softwareintensiver Systems 

Was ist ein Modell: 

• Eine vereinfachte („abstrakte“) Wiedergabe eines Produkts 

(„Systems“) in einer bewährten Form (mit wohlverstanden Mitteln) 

für einen bestimmten Zweck 

Was ist eine Beschreibung eines Modells: 

• Text, Graphik, Tabellen die bestimmte Eigenschaften eines Produkts 

(„Systems“) beschreiben 

Wichtige Ziele: 

• Verständlichkeit 

• Präzision 

Was ist eine Anforderung 

• Geforderte Eigenschaft für ein System 

Was ist eine (Anforderungs-)Spezifikation: 

• Die genaue und vollständige Festlegung aller Eigenschaften eines 

Produkts („Systems“) 


Manfred Broy 12

Vom Nutzen der Modelle 

• Ein Modell erlaubt ein konkrete Darstellung bestimmter 

Aspekte oder einer Perspektive eines Systems 

! Erfassung und Erkenntnis 

! Dokumentation 

! Formalisierung 

! Analyse 

! Weiterverwendung 

• Modelltransformation 

• Codeerzeugung 

• Produktlinien 

• Modelle 

! strukturieren die Sichten auf ein System 

! erfassen Anwender- und Entwicklerwissen 

! geben eine Richtschnur für den Entwicklungsprozess 



Beobachtungen zum Modelleinsatz heute 

• Modellansätze in Anforderungen nur wenig vertreten 

• Heute in der Praxis oft nur lokale Optimierungen 

! Einzelaspekte werden isoliert betrachtet und verbessert 

(Beispiel: Standardisiertes Lastenheft ohne Betrachtung von Test 

oder Architekturimplikationen) 

• Modelle werden nur halbformal erfasst - 

Modellierungssprachen sind nicht formalisiert 

! Tiefergehender Nutzen ist nicht abgreifbar (Beispiel: 

Konsistenzüberprüfungen, Generierung von Tests aus Modellen) 

• Standardisierung in der Kommunikation zwischen 

Unternehmen noch unzureichend 

! Modelle können nicht ausgetauscht werden, bzw. nicht als 

Referenz für Schnittstellen verwendet werden 


Manfred Broy 14

Modellbasierung ist mehr als Dokumentation 

Modellbasierung unterstützt (im Idealfall): 

• Unmissverständliche Beschreibung 

• Wohldefinierte Sichten und Ebenen der Abstraktion 

• Maschinenverarbeitbare Beschreibungen 

• Rechnergestützte Analyse 

! Konsistenzsicherung 

• Automatische Extraktion von Information für 

Nachfolgeschritte 

• Frühe Qualitätssicherung 

! Verifikation 



Informelle 

Anforderungen 

Modellbasierung in der Entwicklung 

Formalisieren 

S 

Requiremerments 

Engineering 

Validierung 

Formalisierte 

Systemanforderungen 

Systemabnahme 

Systemverifikation 

R & S 

Integration 

R = R1)R2)R3)R4 

R 

Ausliefern 

R1 

R2 

R4 R3 

Architektur 

Architekturdesign 

Architekturverifikation 

S = S1)S2)S3)S4 

S1 

S4 

S2 

S3 

Realisieren 

R1 

Integrieren 

R2 

R4 R3 

Komponentenimplementierung 

-verifikation 

R1 & S1 

R2 & S2 

R3 & S3 

R3 & S4 


Manfred Broy 16

Theorie der Modellierung von Systemen 

• Schnittstellensicht - Schnittstellenspezifikation 

• Hierarchischen Architekturen durch Komposition/Dekomposition 

• Realisierung durch Zustandsmaschinen 

• Dekomposition des Systems in gesteuerte und steuernde 

Teilsysteme 

• Modularität 

• Mult-Sichtenmodell 

• Sichten integrieren 

• Systemmodelle vervollständigen 

• Verfeinerung 

• Wechsel der Abstraktionsebene 

• Schichtenansatz 

• Abbildung auf Logik 

• Grundlage für Engineering 

• Ein-/Ausgabe, Ursache/Wirkungsbeziehung, Kausalität 

• Nichtdeterminismus/Unterspezifikation 



Modelle anschaulich: Beispiel: Zustandsübergangsdiagramm 

x:Data 

Sender 

bs: Bit 

d: Data 

c1:M 

c4:Bit 

x:e / - {d := e} 

- / c1:m(d,bs) 

{bs := true} 

Input 

Transmission 

- / - 

{bs = ¬t} c4:t/- 

Waiting 

{bs = t} c4:t / - {bs := ¬bs} 


Manfred Broy 18

Communication Network 

Weitere Systemsichten 

• Prozess/Ablauf: 

Medium 

Darstellung des Verhaltens eines Systems durch Mengen von 

Ereignissen/Aktionenen und ihre zeitlichen/kausalen Abhängigkeiten 

Beispiel: Interaktionsdiagramme, MSCs, Occurrence Network Manager Netze, 

Geschäftsprozessdiagramme 

• Architektur: 

Menge von Komponentenidentifikatoren, belegt mit Komponenten mit 

verträglichen syntaktischen Schnittstellen 

Komponenten können dargestellt werden durch: 

! Schnittstellenverhalten, 

! Zustandsmaschinen, 

! Architekturen, 

Sender 

! Prozesse. 

Wir erhalten eine hierarchische Systemsicht 

Medium 

Receiver 



Theorie der Modellierung verteilter Systeme 

• Schnittstellenabstraktion: Jede Zustandsmaschine, jeder 

Prozess und jede Architektur kann zu einem 

Schnittstellenverhalten abstrahiert werden 

• Komposition: 

! Auf jeder Systemsicht (Schnittstelle, Zustandsmaschine, 

Architektur, Prozess) ist ein Kompositionsoperator gegeben 

! Die Kompositionsoperatoren sind verträglich 

• Verfeinerung: 

! Auf jeder Systemsicht (Schnittstelle, Zustandsmaschine, 

Architektur, Prozess) ist ein Kompositionsoperator gegeben 

! Die Verfeinerungsoperationen sind verträglich 

! Verfeinerung und Komposition sind verträglich 


Manfred Broy 20

abstraction 

abstraction 

abstraction 

Theorie der Modellierung: Meta Model 

Composition 

Refinement 

Time 

Feature model 

Interface model: components 

Input and output 

uses 

Implementation 

uses 

Composition 


Time 

Process transition model: 

Events, actions and causal relations 


state transition model: 

states and state machines 

uses 

Data model: 

Types/sorts and characteristic functions 

Composition 


Time 

Is sub-feature 

Hierarchy 

and 

Architektur 

Composition 


Time 



Herausforderung: Modellierung Architektur 

• System Dekomposition/Komposition 

• Hierarchie 

• Komponenten 

! Rollen 

! Interaction 

! Schnittstellenverhalten 

• Nichtfunktionale Aspekte 

! Performanz 

! Zuverlässigkeit 

• Architekturvalidierung und -bewertung 

• Aspekt-orientierte Sichten auf Architekturen 


Manfred Broy 22

Kritisch: Schnittstellenmodellierung und -spezifikation 

Unsere heutigen praktischen Methoden zur Modellierung 

von Schnittstellen sind ungenügend: 

• Nutzungsschnittstellen 

! Nicht nur Oberfläche sondern auch Verhalten 

• Komponentenschnittstellen 

! Nicht nur syntaktische Schnittstellen, sondern auch Verhalten 

Schlüsselfrage: Modellierung der Interaktion 

• Sequenzdiagramme sind oft nicht ausdrucksstark genug 

• Zustandsmaschinen sind oft zu implementierungslastig 

• Problem im OO: 

! Methodenaufrufe zu unflexibles Konzept! 

! Kein brauchbarer Komponentenbegriff 



Durchgänge Modellierung und QS 

Aufgaben Modellierung 

• Modellierung Anforderungen 

! Featurehierarchie 

! Featuremodelle 

! Abhängigkeiten 

• Architektur 

! Komponentenlayout 

! Interaktionsszenarien 

! Schnittstellen 

• Module 

! Schnittstellen 

Aufgaben QS 

• Validierung 

• Virtuelle Architekturverifikation 

• Modulverifikation 

! Review 

! Inspektion 

! Test 

• Integration 

! Review 

! Inspektion 

! Test 

• Software/Systemintegration 

• Systemtest 


Manfred Broy 24

Modellierungstechniken und ihre Verwendung 

Modellierungstechniken 

• Datensicht 

! Abstrakte Datentypen 

! E/R Diagramme 

! Klassendiagramme 

• Schnittstellensicht 

! Use Cases und Featurebäume 

! Schnittstellenspezifikationen 

• Zustandssicht 

! Zustandsmaschinen 

• Ablaufsicht 

! Interaktionsdiagramme 

! Prozessdiagramme 

! Ablaufdiagramme 

• Struktursicht 

! Komponentenstrukturdiagramme 

! Klassendiagramme 

Phasen 

• Analyse und 

Anforderungsspezifiaktion 

• Design: Architekturentwurf 

• Implementierung 

• Modultest 

• Integration 

• Integrationstest 

• Systemtest 



Die Fülle der Modellierungsthemen 

• Datenmodelle 


Manfred Broy 26



• Modelle von Schichtenarchitekturen 






• Dienstmodellierung 


Manfred Broy 28





• Gesamtarchitektur 

Kundenfunktionsordnungsstrukt 

ur 

Logische Architektur 

Technische Architektur 

Konzeptionelle Architektur 

Tasks 

T1 

T2 

T3 

T4 

... 

Software Architektur 

Deployme 

nt 

T1 

... 

T2 

... 

T3 

T4 

... 

Hardware Architektur 








• Systemmodelle 

abstractio 

n 

abstraction 

Compositi 

on 

Refineme 

ntTime 

Feature model 

Schnittstellenmodel: components 

Input und output 

abstraction 

uses 

Compositi 

on 


ntTime 

Implementati 

on 

uses 


Events, actions und causal relations 

Is subfeature 

Compositi 

on 


ntTime 

Implementati 

on 

zustand transition model: 

zustands und zustand machines 

uses 

Hierarchy 

und 

Architektur 

Compositi 

on 


ntTime 

Data model: 

Types/sorts und characteristic funktions 


Manfred Broy 30







• Vorgehensmodelle 










• Prozessmodelle 


Manfred Broy 32









• Qualitätsmodelle 












• Meta-Modelle 


Manfred Broy 34










• Meta-Modelle 

Kundenfunktionsordnungsst 

ruktur 

Logische Architektur 

Konzeptionelle Architektur 

Technische Architektur 

Tasks 

Software Architektur 

T1 

T2 

T3 

Deploy 

T4 

ment 

... 

T1 

... 

T2 

... 

Hardware Architektur 

T3 

T4 

... 

Abstraktion 

Abstraktion 

Abstraktion 

Composition 


Time 

Composition 

Hierarchy 


und 

Feature model 

Time 

Architektur 

Is sub-feature 

Schnittstellenmodel: components 

Input und output 

Composition 



Time 

uses 


Events, actions und causal relations 

Composition 



Time 

uses 

zustand transition model: 

zustands und zustand machines 

uses 

Data model: 

Types/sorts und characteristic funktions 



Universelle vs. domänenspezifische Modellierungsansätze 

Universelle Modellierung: 

• „One Size fits all“: Ein universeller Modellierungsansatz 

(„Modellierungssprache“) 

! Software 

! Hardware 

! Anwendungen 

! Mechatronik 

Domänenspezifische Modellierung: 

• Auf Domänen (Anwendungsgebiete) zugeschnittene 

Modellierungsansätze („Modellierungssprachen“) 

! Telekommunikation 

! Adaptive Systeme 

! Mobile Systeme 

! Geschäftsprozesse 

! Workflow 

! Nutzerschnittstellen 

! ... 


Manfred Broy 36

Zusammenfassung: Modellierung von Software und QS 

• Modellorientierung und QS ergänzen sich ideal 

! Formalisierung als Voraussetzung für QS 

• Validierung 

• Verifikation 

• Test 

! Mehrwert bei vielfältiger Nutzung der Modelle 

• Durchgängigkeit wird heute noch nicht erreicht 

! Modellansätze nicht formal genug 

! QS zu wenig automatisiert und in Werkzeuge integriert 

! Modelle werden nicht konsequent genutzt 

! Übergang zwischen Modellen nicht verstanden 

! Integration von Modellsichten unzureichend 


Manfred Broy 37

Modellierung in der Software- und Systementwicklung

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?