What does Software Engineering need to become an Engineering Discipline?

(1)

SOFTWARE DESIGN AND QUALITY GROUP

INSTITUTE FOR PROGRAM STRUCTURES AND DATA ORGANIZATION, FACULTY OF INFORMATICS

What does Software „Engineering“ need

to become an Engineering Discipline?

(2)

Engineering Development

[Shaw&Garlan95]

Craft

• 

Customer and user

often same person

• 

Experience and

talent Instead of

systematic methods

Manufacturing

• division of labor

• trained specialists

• use of specialized tools

Engineering

• 

Understanding the

impact of design

Decisions before

implementation

• 

Through understanding

of products and

production processes

Theories are needed

(3)

What do we need?

  Systematic exploration of the design space

  Understanding of the impact of design decisions

  Expressing and changing designs (much faster than code)

  This enables:

  Truly Agile developmemt

  less try and error

  less permanent re-invention of wheels

  avoidable refactoring efforts

Automatisation (optimisation) where possible

  Better designs

(4)

Two projects

(actually all my research life)

  Palladio (Methods and Tools for Predicting

Performance and Reliability of Component-Based

Software Engineering)

  Vitruvius (VIew-cenTRic engineering

Using a VIrtual Underlying Single

model)

Marcus Vitruvius Pollio

(80–70b.c. – 15b.c.)

Andrea di Piero della

Gondola, genannt

Palladio

(5)

Simulation of Software Architectures

Palladio: (www.palladio-simulator.com)

  CV:

  2003-2008 DFG funded project

(„Aktionsplan Informatik“, Emmy-Noether),

  2007-2011 EU funded

  2010 till today: open source and

Industry (ABB, IBM, ...) and public funding

(KIT, FZI, UPB, TU Chemnitz, Univ. Zürich, ...)

comprising

1.  Architectural Modelling Language

2.  Simulator for performance, ressource utilisation,

reliability, (energy consumption) and maintainability

3.  Design Method

(6)

Treatment of Quality Properties Today

4. Re-Implementing /

Re-Designing /

Re-Negotiating

1. Specification

3. Testing

2. Ignoring

(7)

Why do we want to predict

quantitative Properties?

Dimensioning of Resources

(“Sizing”)

vs.

Changes of usage profile –

Scalability

vs.

Evaluation of

Design Alternatives

▪  the quantifiable best of a list of many

▪  trade-off decisions

–  cost vs. benefits

–  QA a vs. QA b

View

Model Controller

View

_View

View

Model Controller

View

vs.

(8)

Empirical Case Study:

How wrong Intuition can get

Training SPE (2 Stunden) SPE-Übungszettel (21 korrekte Abgaben) Training CP (2 Stunden) CP Übungszettel (12 korrekte Abgaben) Training umlPSI (2 Stunden) umlPSI Übungszettel (3 korrekte Abgaben)

Erstellung Performance Modell Modellierung Alternative 1a Modellierung Alternative 1b Modellierung Alternative 2 Modellierung Alternative 3 Modellierung Alternative 4

Experiment

Übung

24 Personen 8 Personen 8 Personen 8 Personen SPE (2 Stunden) CP (2 Stunden) umlPSI (2 Stunden) Besprechung Musterlösung (2 Stunden) Bewertung Alternative 1a Bewertung Alternative 1b Bewertung Alternative 2 Bewertung Alternative 3 Bewertung Alternative 4 Ohne Verfahren 7 Personen

Intuitive Bewertung

(9)

Web Server

C# implemented

Component based

Dispatcher DispatcherThread AnalyzerRequest Request Processor

Static File Provider CGI - Interface ExtAppInterface WebService DB Access DB Exe - Engin

HTTP _IAcceptRe quest IParse Reque st IServe Reque st H T T P IM on ito rW eb se rv er IDel iver Res pons e IGetRe sponse Stream ExtApp

(10)

Design Alternatives

1. 

Cache

Static: Memory ó Hard disk access

Dynamic: Memory ó Network access

2. 

Single threaded Server

Context switch ó response time

3. 

Compression

Processor time ó Bandwidth

4. 

Clustering

(11)

Usage Scenario

40% requests for static pages (HTML, JPG)

60% requests for dynamic pages (HTML)

file size 5 KByte

Client ð Web Server: ISDN (64 KBit/s)

Web Server ð DB-Server: Ethernet (10 MBit/s)

Computation on DB-Server: 0.5 seconds

(12)

Results

0,0 0,5 1,0 1,5 2,0 2,5 3,0 3,5 Teilnehmer D u rc h la u fze it in S e k u n d e n 0: keine Optimierung 1,1928 2,9415 0,9562 1,3168 1,5503 1,8476 2,3094 0,6845 1,5100 0,7009 1a: statischer Cache 1,1883 2,9338 0,9499 1,3108 1,5196 1,8204 2,3030 0,6200 1,5300 0,7055 1b: dynamischer Cache 1,1317 2,8670 0,8981 1,2545 1,4868 1,7826 2,1478 0,5800 1,4400 0,6910 2: single-threaded 0,9546 1,3482 1,5477 1,8428 2,3944 1,5600 0,4874 3: Komprimierung 0,8188 1,6856 0,7096 0,8766 1,2979 1,1221 1,8822 0,6089 0,8100 0,5370 4: Clustering 1,1952 2,9367 0,9588 1,3152 1,5323 1,8421 1,9892 0,6878 1,6500 0,6656

1 2 3 4 5 6 7 8 Messung mitt. quad.

Abweichung

(13)

Model-based Prediction of

Quantitative Properties

Software

Design Model

Annotated

Software

Design

Model

Analysis

Model

Analysis

Results

UML,

ADL,

…

UML Performance

Profile, QML, …

Queuing models

Stochastic Petri-Nets,

Stochastic Process

Algebra,

…

Response time

Throughput,

Utilisation,

…

Estimation

Measurement

Transformation

(MDD)

Analysis /

Simulation

Results

Automated

by Tools

Executable

Software

Transformation

(MDD)

(14)

Scientific Approach to Create

Quantitative Models

Software

Modell of Software

(with Annotations)

Measured Quality

Predicted Quality

Comparison

Abstraction

Prediction

Measurement

Interpretation

Acceptance / rejection

of abstract model

Improvement / Extension

(15)

Validation of Quantitative Models

Type 1: Validation of Prediction Model

Type 2: Validation of Applicability

Case Studies and Controlled Experiemts

with Students

Typ 3: Validation of Benefits

in comparison to different methods

Limitations of the Approach

Required prerequisites

FZI

(16)

Dom. Exp.

DSL Instance

Sys. Depl.

DSL Instance

Soft. Arch.

DSL Instance

Comp.Dev.

DSL Instance

Stochastic

Regular Expr.

Analysis

SPA with

Scheduling

Analysis +

Simulation

Queueing

Network

Performance

Prototype

Java Code

Skeletons

Transformation

Simulation

Execution +

Measurement

Completion +

Compilation

Instance

Part of

Palladio

Component

Model

(17)

Component

(18)

(19)

Factors on Quantitative Component

Properties

(20)

Execution Time of a()?

ComponentA

ComponentB

a()

b()

c()

ComponentC

d()

?

ms

2m

s

3m

s

5m

s

Service Effect Specification

(SEFF)

(21)

Tool Support

(22)

Results

0,00

0,01

0,02

0,03

0,04

0,05

0,06

0,07

0,08

0

1

2

3

4

5

6

7

8

9

10

11

12

13

Pr

o

b

ab

ili

ty

(23)

Results

0,0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1,0

0

1

2

3

4

5

6

7

8

9

10

11

12

13

C

u

m

u

la

ti

ve

Pr

o

b

ab

ili

ty

Response Time (Seconds)

(24)

Two projects (actually all my research

life)

  Palladio (Methods and Tools for Perdicting

Perforamce and Raliability of Component-Based

Software Engineering)

  Vitruvius (VIew-cenTRic engineering

Using a VIrtual Underlying Single

model )

Marcus Vitruvius Pollio

(25)

Why are views important?

  We need several views

  Different roles, different expertise, sheer size

  Consequently, all engineering disciplines have

various different views (in form of plans, charts,

lists, etc describing one system)

  Only in software “engineering” people

wrongly think, code is the sole artifact

(“code-centric development”). Reasons:

  Avoidance of high costs of manual modelling

and consistency keeping

  Historic understanding of software: code

contains all information

(26)

Motivation scenario: Software

Engeneering

component model WebGUIImpl UiInfo GUILayout class diagram «implements»

public classWebGUIImplimplementsIHTTP {

publicFile HTTPDownload (Request request) {

//Handle request } } source code «refines» simulation results «describes performance» WebGUIImpl UiInfo implements implements

component-class implementation view «shows elements from»

MediaStore WebGUI WebGUI

component model

WebGUIImpl

UiInfo

GUILayout

class diagram

«implements»

public class WebGUIImpl implements IHTTP {

public File HTTPDownload (Request request) { //Handle request } }

source code

«refines»

simulation results

«describes

performance»

WebGUIImpl

UiInfo

implements implements

component-class implementation view

«shows elements from»

MediaStore

WebGUI

component model

WebGUIImpl

UiInfo

GUILayout

class diagram

«implements»

source code

«refines»

simulation results

«describes

performance»

WebGUIImpl

UiInfo

«shows elements from»

MediaStore

WebGUI

component model

WebGUIImpl

UiInfo

GUILayout

class diagram

«implements»

source code

«refines»

simulation results

«describes

performance»

WebGUIImpl

UiInfo

«shows elements from»

MediaStore

WebGUI

component model

WebGUIImpl

UiInfo

GUILayout

class diagram

«implements»

source code

«refines»

simulation results

«describes

performance»

WebGUIImpl

UiInfo

«shows elements from»

MediaStore

WebGUI

component model

WebGUIImpl

UiInfo

GUILayout

class diagram

«implements»

source code

«refines»

simulation results

«describes

performance»

WebGUIImpl

UiInfo

«shows elements from»

MediaStore

WebGUI

(27)

Motivation scenario: Engeneering

scenario

«refines»

«similar concepts»

(28)

Problem in the Scenario

Fragmentation

•  information is spread over heterogeneous models

•  mappings are not made explicit

Redundancy

•  same piece of information is represented in multiple elements

Inconsistency

•  arises from redundancy and fragmentation

•  violation of semantic relations

Complexity

•  Users/developers cannot understand entire models

•  navigation is difficult

(29)

Projective vs. Synthetic approach

SUM

view

1

view

2

view

3

view

4

view

5

view

6

view

7

(30)

Backup – Orthographic Software Modeling

(OSM)

Definition: Single Underlying Model (SUM)

(after: Atkinson, Stoll, and Bostan 2010)

•  complete definition of a system

•  contains all information that can be expressed using well-defined

description formalisms

•  displayed or manipulated exclusively by specific views

•  described by a SUM metamodel

•  the SUM metamodel is method- or project-specific

Views and View-types

•  Views are normal models that have been generated dynamically

contain only transient information which is generated from the SUM

•  View Types are the metamodels of which the views are instances

State of the art

Vitruvius approach

Views

Conclusion

(31)

A modular SUM metamodel

PCM

UML

Java

Sensor

MIR MIR

C

1

C

2

C

3

UML class

diagram view

VT

1

C

1

C

2

imple-ments imple-ments

component-class

implementation view

VT

2

VT

3

component diagram view

VT

4

simulation results view

VT

5

@ADLImplements(implements-component comp_1)

public class C2 extends C1 {

public static void main (String[] args) { }

}

annotated Java source view

VT

6

VT

projectional view type

VT

combining view type

MIR

mapping/invariant/response

comp1

(32)

Benefits of the modular SUM

metamodel

Modularity

•  semantic relations btw. sub-models made explicit in MIR elements

•  re-useof sub-metamodels and MIR definitions

Compatibility

•  existing sub-metamodels need not be modified

•  compatibility to existing tools and transformations

Evolution

•  sub-metamodels can evolve independently

(33)

Development process

MM2

MM1

MM3

MM4

MIR MIR

methodologist

developer

SUM

metamodel

defines

uses

VT

view

flexible view

(34)

(35)

Software Design and Quality Group

Backup – Vitruvius: Synchronization

Process

methodologist

developer

metamodels

1. adds

mappings

map

specifies

2.

invariants

constrain

3.

responses

restore

4.

generator

input

5. executes

correspondence mm

incremental sync

transformations

6. produces

maintain instances

view type

based on

view

instantiates

7. uses

8. triggers

methodologist

developer

metamodels

1. adds

mappings

map

specifies

2.

invariants

constrain

3.

responses

restore

4.

generator

input

5. executes

correspondence mm

incremental sync

transformations

6. produces

maintain instances

view type

based on

view

instantiates

7. uses

8. triggers

methodologist

developer

metamodels

1. adds

mappings

map

specifies

2.

invariants

constrain

3.

responses

restore

4.

generator

input

5. executes

correspondence mm

incremental sync

transformations

6. produces

maintain instances

view type

based on

view

instantiates

7. uses

8. triggers

methodologist

developer

metamodels

1. adds

mappings

map

specifies

2.

invariants

constrain

3.

responses

restore

4.

generator

input

5. executes

correspondence mm

incremental sync

transformations

6. produces

maintain instances

view type

based on

view

instantiates

7. uses

8. triggers

methodologist

developer

metamodels

1. adds

mappings

map

specifies

2.

invariants

constrain

3.

responses

restore

4.

generator

input

5. executes

correspondence mm

incremental sync

transformations

6. produces

maintain instances

view type

based on

view

instantiates

7. uses

8. triggers

methodologist

developer

metamodels

1. adds

mappings

map

specifies

2.

invariants

constrain

3.

responses

restore

4.

generator

input

5. executes

correspondence mm

incremental sync

transformations

6. produces

maintain instances

view type

based on

view

instantiates

7. uses

8. triggers

methodologist

developer

metamodels

1. adds

mappings

map

specifies

2.

invariants

constrain

3.

responses

restore

4.

generator

input

5. executes

correspondence mm

incremental sync

transformations

6. produces

maintain instances

view type

based on

view

instantiates

7. uses

8. triggers

methodologist

developer

metamodels

1. adds

mappings

map

specifies

2.

invariants

constrain

3.

responses

restore

4.

generator

input

5. executes

correspondence mm

incremental sync

transformations

6. produces

maintain instances

view type

based on

view

instantiates

7. uses

8. triggers

(36)

Research Goals & Questions

Research Goals

•  ease consistent synchronization of heterogeneous models

•  support views on heterogeneous models using sync information

Research questions I

•  Can we synchronize heterogeneous models automatically?

•  Can we specify synchronization with a precise & expressive MIR

DSL?

•  Can we define mapping equivalence classes & normal forms with

maximal coverage?

•  Can we generate sync. transform. from these mapping normal

forms?

•  Can we sync models by triggering these transform. on atomic

changes?

(37)

A DSL for Abstract Consistency

  declarative synchronization rules

  normative invariants

(38)

Views in Vitruvius

Views

•  a view can represent several (possible heterogeneous) elements

•  the is represented by-relation is surjective, but in general not

bijective

(39)

Editability in views

v

1

original view

edit

v

⇤

1

dirty view

save

consistency

conservation

operation

triggers

consistency

check

SUM not consistent

v

0

1

saved view

SUM consistent

(40)

Ad-hoc definition of flexible views:

ModelJoin

(41)

Software Design and Quality Group

Backup – Views: ModelJoin I

ModelJoin: a textual description language for

flexible views

Inspired by SQL

Declarative description of projectional and

selectional scope

Example: Flexible view for PCM and sensor

metamodel:

ModelJoin I

ModelJoin: a textual description language for flexible views

Inspired by SQL

Declarative description of projectional and selectional scope

Example: Flexible view for PCM and sensor metamodel:

theta join Entities.TimeSpanSensor with pcm.core.composition.AssemblyContext

where "TimeSpanSensor.sensorName.indexOf(AssemblyContext.id) > 0" as jointarget.

AssemblyContext {

keep attributes pcm.core.entity.NamedElement.entityName, Entities.Sensor.

sensorName

keep outgoing pcm.core.composition.AssemblyContext.

encapsulatedComponent__AssemblyContext as type jointarget.Component {

keep attributes pcm.core.entity.NamedElement.entityName

keep subtype pcm.repository.BasicComponent as type jointarget.

BasicComponent

keep subtype pcm.repository.CompositeComponent as type jointarget.

CompositeComponent }

(42)

Backup – Views: ModelJoin II

ModelJoin II

keep attributes Entities.Experiment.experimentName, Entities.Experiment.

experimentID

keep outgoing Entities.Experiment.experimentRuns as type jointarget.Run {

keep attributes Entities.ExperimentRun.experimentRunID, Entities.

ExperimentRun.experimentDateTime

keep aggregate size(Entities.ExperimentRun.measurements) as

jointarget.Run.measurementCount,

avg(Entities.TimeSpanMeasurement.timeSpan) over Entities.

ExperimentRun.measurements as jointarget.Run.avgTime,

min(Entities.TimeSpanMeasurement.timeSpan) over Entities.

ExperimentRun.measurements as jointarget.Run.minTime,

max(Entities.TimeSpanMeasurement.timeSpan) over Entities.

ExperimentRun.measurements as jointarget.Run.maxTime

} }

(43)

Conclusion

Vitruvius

•  view-based, model-driven engineering approach Based on OSM

[Atkinson, Stoll, and Bostan 2010]

Views

•  Views defined by methodologist

•  Flexible views for ad-hoc definition of views by user

Development process

•  methodologist and user as roles

Planned Contributions

•  declarative definition of view types and views

(44)

Conclusions

Prediction and Understanding of the

Consequences of Design Decisions is THE

central characteristic of an engineering

discipline.

Palladio is a first step in this direction

Creativity shifts to the design-model level

Code is also only a view (and not the full the

truth!)

(45)

http://sdq.ipd.kit.edu

http://www.palladio-simulator.com

What does Software Engineering need to become an Engineering Discipline?

SOFTWARE DESIGN AND QUALITY GROUP