lecture 06 08102010 empirical software -...

10/8/10

1

FEEDBACK ON FIRST MINI PROJECT

 Structure: introduction  Bibliography: technical reports  LaTeX style: article versus report  What is a good summary?

  right level of details   specific yet general   what is the story? the main contribution?   context, problem, solution

10/8/10

1

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

SCIENTFIC METHODS FOR SOFTWARE ENGINEERING (Alternative title: Scientific Methods versus Software Engineering)

Ulrik Pagh Schultz, MMMI, SDU

SCM’10, 8/10-2010

SOFTWARE ENGINEERING

 Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. [Bauer’69]

 Systematic approach   process: framework for delivery of software, enables

rational and timely delivery of software   method: communication, analysis, design,

construction, testing, ...   tools: semiautomated support for processes and

methods languages: used at all levels, more or less formally

10/8/10

3

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

PROCESSES

 Software development process: manufacturing process that a team follows throughout lifetime of software

 Process types, e.g.:   none=unstructured (we just do stuff)   waterfall (analyze, implement)   agile (incremental, iterative, customer-oriented)

 Empirical experiments? Observations!   consultants rescuing projects (agile origins)   companies experimenting (e.g., Systematic A/S

adopting SCRUM and IBM developing their own methodologies)

10/8/10

4

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

METHODS

 Software development methods: techniques used to produce software

 Methods for every step in the lifetime:   analysis, design, architecture, ... (e.g., UML)   implementation (programming languages,

algorithms, idioms, patterns, ...)   communication (peer programming, ...)   testing (unit testing, integration testing, ..)   ...

 Empirical experiments?   efficiency with which software can be produced   quality of software produced (reliability, speed, ...)

10/8/10

5

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

TOOLS

 Software development tools: computer tools that support methods and process

 Tools for every step in the lifetime:   unified process analysis and design   editor, compiler, debugger   source code management

 Empirical experiments!   efficiency: still hard, but doable   quality: quantitative experiments feasible in many

interesting cases (but do they generalize?)

10/8/10

6

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

10/8/10

2

EMPIRICAL SOFTWARE ENGINEERING: WHAT TO DO?

 Processes are notoriously difficult  Empirical experiments with tools can be very

resource consuming  Methods are somewhere in between (UML is

harder, algorithms are easier)  Use appropriate scientific methodology:

  controlled experiments   case studies   survey studies   ethnographical studies   software metrics   benchmarks

10/8/10

7

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

EMPIRICAL SOFTWARE ENGINEERING: CONTROLLED EXPERIMENTS

 Manipulate one or more independent variables to measure their effect on dependent variables

 Human subject: measure effect of treatment on a population of subjects

 Examples:   quantitative: program specialization (various

efficiency measures, program size) [TOPLAS’03]   qualitative: simulator GUI [Kuznecovas MS]

 Precondition: clear hypothesis  Difficult to generalize (e.g., efficiency for a

specific task versus general usefulness)

10/8/10

8

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

EMPIRICAL SOFTWARE ENGINEERING: CASE STUDIES

 Empirical query that investigates a phenomenon in its real-life context

 Potential advantages:   in-depth understanding of how and why phenomena

occur as well as causal relationships   exploratory case studies (demonstrator)   confirmatory case studies (can refute theory)

 Precondition: clear research question  Examples:

  automatic specialization of OoLaLa [TOPLAS’03]   DSL for web-based strategy games [Yetkin MS]

 Advantageous when context is important

10/8/10

9

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

EMPIRICAL SOFTWARE ENGINEERING: SURVEY RESEARCH

  Identifies characteristics of a broad population of individuals   representative sample from a well-defined population   generalize using data analysis techniques

 Challenges:   identifying representative subset of population   sampling bias etc.   phrasing questions for useful and valid data

 Examples:   simulator GUI requirements and utility [Kuznecovas

MS]   evaluating utility of specific technologies   identifying concerns among practitioners

10/8/10

10

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

EMPIRICAL SOFTWARE ENGINEERING: ETHNOGRAPHICAL STUDIES

 Goal: study a community of people to understand their social interactions

 Software engineering?   understand technical communities   build techniques for communication and collaboration

 Advantage: does not impose pre-existing theories  Precondition: research question focusing on

cultural practices  Example:

  evaluating agile software development practices   software for modular robots (action research)

10/8/10

11

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

EMPIRICAL SOFTWARE ENGINEERING: SOFTWARE METRICS?

 Measurement is key to an engineering process  Difficult to measure software

  metrics are often indirect   qualitative properties: correctness, reliability,

efficiency, usability, maintainability, flexibility, ...

 Key properties of a metric:   mathematical properties (range, ...)   represents a software characteristic that increases

when positive traits occur, and vice versa   validated empirically in a wide range of contexts   simple and computable

10/8/10

12

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

10/8/10

3

WHAT SOFTWARE METRICS?

 Analysis: size, specification quality, ...  Design: structural complexity, data complexity

  OO: size, complexity, coupling, similarity, ...   CK metrics: weighted methods per class, depth of

inheritance tree, number of children, coupling between classes, ...

  Others: method inheritance factor, ...

 Source code: size, branches, nesting, ...  Testing: code coverage, range coverage, ...  Maintenance: software maturity index

(1.0=stable)

10/8/10

13

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

EMPIRICAL SOFTWARE ENGINEERING: BENCHMARKS (RUNTIME METRICS)

 Runtime performance of a program:   running time (operation, continuous, one-shot, ...)   resource usage (memory, threads, ...)   communication (throughput, latency, ...)   degree of success

 Difficult to monitor without interfering  Hard to make reproducible results in a complex

environment   VM-based execution (JIT, GC, ...)   multithreaded or distributed program   real-world execution vs. lab execution

10/8/10

14

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

EMPIRICAL SOFTWARE ENGINEERING

 Software engineering is by nature very broad   how to talk to customers vs. optimizing compilers   needs a broad perspective on what scientific methods

to use

 Case studies:   Language design I: ownership types   Language design II: aspect-oriented programming   Domain-specific languages for device drivers   Software engineering for modular robots

 Conclusions:   specific subdomains have their own practices   empirical studies could be used more often, but at a

price in terms of progress

10/8/10

15

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

LANGUAGE DESIGN CASE STUDY: OWNERSHIP TYPES

JDK 1.1.1 SECURITY HOLE

public class Class {! private Object[] signers;! private Class() { ; }! public native String getName();! public native boolean isInterface();! public native boolean isPrimitive();! public String toString() {! return (isInterface() ? "interface “ ! : (isPrimitive() ? "" : "class ")) ! + getName();! }!

...! public Object[] getSigners() {! return signers;! } ! void setSigners(Object[] signers) {! if(this.signers!=null) ! throw new SecurityException(...);! this.signers = signers;! }! ...!}!

Note: same security hole but wrong code in some places

10/8/10

17

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

DIFFERENT APPROACHES TO OWNERSHIP

 Early attempts:   Islands [OOPSLA’91] and Balloons [ECOOP’97]: full

encapsulation with static and dynamic aliases   Aliasing modes [ECOOP’98]: control aliases, side

effects, and dependencies on mutable state

 Type-based approach (for Java): Ownership types for Flexible Alias Protection [OOPSLA’98]   distinguish representation and non-representation

objects (similar to earlier work)   simple, modular, type-based approach

10/8/10

18

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

10/8/10

4

BASIC EXAMPLE: VECTOR

class Vector {! private Object[] contents;! Vector(int size) {! contents = new Object[size];! }! Vector(Object[] elms) {! this.contents = elms;! }! Object get(int i) { ! return contents[i]; ! }! Vector copy() {! return new Vector(contents);! }!}!

class Vector {! private rep Object[] contents;! Vector(int size) {! contents = new rep Object[size];! }! Vector(norep Object[] elms) {! contents = new rep Object[elms.length];! for(int i=0;i<elms.length;i++)! contents[i] = elms[i];! }! norep Object get(int i) { ! return contents[i]; ! }! norep Vector copy() {! return new norep Vector(contents);! }!}!

10/8/10

19

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

JDK 1.1.1 SECURITY HOLE: FIXED

public class Class {! rep private Object[] signers;! ...! rep public Object[] getSigners() {! return signers;! } ! void setSigners(rep Object[] sign) {! if(this.signers!=null) ! throw new SecurityException(...);! this.signers = sign;! }! ...!}!

public class Class[ownr] {! ownr private Object[] signers;! ...! ownr public Object[] getSigners() {! return signers;! } ! void setSigners(ownr Object[] srs) {! if(this.signers!=null) ! throw new SecurityException(...);! this.signers = srs;! }! ...!}!

Note: same security hole but wrong code in some places

Basic solution: representation containment (not quite enough)

Improved solution: parameterized representation containment

10/8/10

20

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

VECTOR WITH ITERATOR?

class Vector {! private rep Object[] contents;! Vector(int size) {! contents = new rep Object[size];! }! Vector(norep Object[] elms) {! contents = new rep Object[elms.length];! for(int i=0;i<elms.length;i++)! contents[i] = elms[i];! }! norep Object get(int i) { ! return contents[i]; ! }! norep Vector copy() {! return new norep ! Vector(contents);! }! norep Iterator iterator() {! return new norep ! VectorIterator(contents);! }!}!

class VectorIterator implements Iterator {! private rep Object elements;! private int index;! VectorIterator(??? Object elements) {! this.elements = elements;! }! norep Object next() {! return elements[index++];! }! boolean hasNext() {! return index<elements.length;! }!}!

10/8/10

21

Owner does not help: vector should be the owner, but want to give access to iterator that it should not own

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

VECTOR WITH ITERATOR: FIXED

  Allow inner classes privileged access to representations of outer class objects [POPL’03]

  Numerous followups (36 citations in ACM digital library), e.g. for controlling side-effects

class Vector {! private rep Object[] contents;! Vector(int size) {! contents = new rep Object[size];! }! ...! class VectorIterator implements Iterator {! private int index;! norep Object next() {! return contents[index++];! }! boolean hasNext() {! return index<contents.length;! }! }!}!

10/8/10

22

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

ANALYSIS AND ASSESSMENT

 Case studies used as benchmarks   concrete problems (e.g., Java security hole)   common problems (e.g., implementation of design

patterns)   language features often evolve around sets of “hard”

problems

 Good:   common ground for comparison   focus on hard and relevant problems

 Not so good:   no idea if proposed idea is generally useful   toy languages solve toy problems

10/8/10

23

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

LANGUAGE DESIGN CASE STUDY: ASPECT-ORIENTED PROGRAMMING (AOP)

10/8/10

5

ASPECT-ORIENTED PROGRAMMING

 Programming paradigm that increases modularity by allowing the separation of cross-cutting concerns, forming a basis for aspect-oriented software development [Wikipedia]   modularity: the separation of software into

independent components, called modules   concern: feature of a program   cross-cutting concerns: concerns that span multiple

modules (e.g., logging, distribution, events, ...)   AOSD: development of software using aspect-oriented

software development techniques

 Numerous languages: AspectJ, CaesarJ, ...

10/8/10

25

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

WHY AOP?

 AOP is motivated by common issues in OO:   many features cross-cut object-oriented structure   encapsulation versus modularity

 Claimed benefit: improved modularity   change propagation   concern (feature) interaction   ripple-effects   better adherence to well-known design principles

 How to verify this claim?

10/8/10

26

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

EMPIRICAL STUDY OF THE IMPACT OF ASPECTUAL DECOMPOSITION

  On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study [ECOOP’07]

  Domain: software engineering / programming language design

  Main point: a large case study (size, releases, implementation languages) can reveal advantages and disadvantages of aspect-oriented designs

  Story: 4000 LOC web-based system implemented in Java, AspectJ and CaesarJ which is subjected to identical change scenarios and analyzed according to their modularity using software metrics, revealing advantages of aspect-oriented decomposition in most but not all cases

10/8/10

27

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

DETAILS: METHODOLOGY AND EXPERIMENTS

  Methodology   OO version was already available, AO versions developed

according to requirements, alignment rules used to assure similarity between implementations

  change scenarios involve additions, changes, and removal of modules (with subsequent alignment)

  evaluation according to software metrics, change impact analysis, and concern interaction analysis

  Experimental results:   AO tends to be more stable and changes less intrusive and

more simplistic   OO and AO high stability in high-level design structures   AO worse for specific designs (e.g., Command and State)

that violate narrow interface and low coupling

10/8/10

28

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

ANALYSIS AND ASSESSMENT

 Good points   empirical, quantitative study of language design

principles   3 languages, 10 change phases

 Less good points   4000 LOC is not really a large program   are the programmers comparable etc?

 Comments & conclusions   thorough description of experimental setup, careful

and detailed analysis of results   software metrics are as always only indicative of

properties

10/8/10

29

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

EMPIRICAL PROGRAMMING LANGUAGE EXAMPLE: DEVIL, DEVICE DRIVERS

Developed in the Compose group at Rennes / Bordeaux, France [where Ulrik did his PhD] Characteristics:

targets specific sub-domain in device drivers (general-purpose language needed to express all parts) complex compilation and verification

[Based on materials from Laurent Réveillère, Project Phoenix, LaBRI, France]

10/8/10

6

10/8/10

SCM'10 - Ulrik P Schultz, MMMI,

SDU

31

DEVICE

CPU

DMA

Memory

Video card Monitor

Scanner

Keyboard

Speakers Sound card

SCSI Ctrl.

Keyboard Ctrl.

•  Inherent Complexity –  Compromise –  Compatibility

•  Informal Specifications

–  Human language –  Mixed levels of

abstractions –  Manufacturer-specific

terminology

10/8/10


SDU

32

1 . . 0 0 0 0 0

base + 2

Direct register * * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

base + 0

Register array index

dx

dy buttons

INTERFACE EXAMPLE: BUS MOUSE

Simplified Functional Interface •  dx : horizontal movement •  dy : vertical movement •  buttons : button state

10/8/10


SDU

33

Device

Driver

Operating system

Application

DEVICE DRIVER

•  Assembly-level programming style

•  Macros –  Tedious, error prone –  Not systematic –  Poor readability –  Dependent on

programming style –  No type / consistency

checking

10/8/10


SDU

34

Device

Driver

Operating system

Application

DEVICE DRIVER

Performance [TOCS'93]

Productivity 70 % of the code

of an OS [SOSP'01]

Robustness Up to 7 times more bugs

[SOSP'01]

10/8/10


SDU

35

DEVICE DRIVER

Device

Operating system

Application

Driver

Algorithmic

OS Interface

Device Interface

Robustness Up to 7 times more bugs

[SOSP'01]

Performance [TOCS'93]

Productivity 70 % of the code

of an OS [SOSP'01]

10/8/10


SDU

36

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

base + 0 dx

dy buttons

Register array

DRIVER EXAMPLE: LINUX MOUSE

1 0 0 0 0 0

index

base + 2

Direct register . .

10/8/10

7

10/8/10


SDU

37

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

base + 0 dx

dy buttons


1 0 0 0 0 0

index

Direct register . .

#define MSE_CONTROL_PORT 0x23e

Register array

base + 2 10/8/10


SDU

38

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

dx

dy buttons


1 0 0 0 0 0

index

Direct register . .

#define MSE_CONTROL_PORT 0x23e #define MSE_DATA_PORT 0x23c

Register array

base + 0 base + 2

10/8/10


SDU

39

Register array

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

dx

dy buttons


index

Direct register

#define MSE_DATA_PORT 0x23e #define MSE_CONTROL_PORT 0x23c #define MSE_READ_X_LOW 0x80

base + 0

1 0 0 0 0 0

base + 2

0 0

10/8/10


SDU

40

Register array

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

dx

dy buttons


index

Direct register

#define MSE_DATA_PORT 0x23e #define MSE_CONTROL_PORT 0x23c #define MSE_READ_X_LOW 0x80 #define MSE_READ_X_HIGH 0xa0

base + 0

1 0 0 0 0 0

base + 2

0 1

10/8/10


SDU

41

Register array

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

dx

dy buttons


index

Direct register

#define MSE_DATA_PORT 0x23e #define MSE_CONTROL_PORT 0x23c #define MSE_READ_X_LOW 0x80 #define MSE_READ_X_HIGH 0xa0 ...

base + 0

1 0 0 0 0 0

base + 2

. .

10/8/10


SDU

42

Register array

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

dx

dy buttons


outb(MSE_READ_X_LOW, MSE_CONTROL_PORT);

1 0 0 0 0 0

index

base + 2

Direct register 0 0

base + 0

10/8/10

8

10/8/10


SDU

43

Register array


outb(MSE_READ_X_LOW, MSE_CONTROL_PORT); dx = (inb(MSE_DATA_PORT) & 0xf);

* * * * . . . . * * * * . . . . . . . * . . . .

dx

dy buttons

* * * * . . 1 0 0 0 0 0 0 0

base + 2

index

Direct register

base + 0

. .

10/8/10


SDU

44

Register array

* * * * . . . .


outb(MSE_READ_X_LOW, MSE_CONTROL_PORT); dx = (inb(MSE_DATA_PORT) & 0xf); outb(MSE_READ_X_HIGH, MSE_CONTROL_PORT);

* * * * . . . . * * * * . . . . . . . * . . . .

dx

dy buttons

1 0 1 0 0 0 0 0

base + 2

index

Direct register

base + 0

10/8/10


SDU

45

Register array


outb(MSE_READ_X_LOW, MSE_CONTROL_PORT); dx = (inb(MSE_DATA_PORT) & 0xf); outb(MSE_READ_X_HIGH, MSE_CONTROL_PORT); dx |= (inb(MSE_DATA_PORT) & 0xf) << 4;

* * * * . . . .

* * * * . . . . . . . * . . . .

dx

dy buttons

* * * * . . . .

base + 0

1 0 1 0 0 0 0 0

base + 2

index

Direct register

10/8/10


SDU

46

Register array * * * *

base + 0


outb(MSE_READ_X_LOW, MSE_CONTROL_PORT); dx = (inb(MSE_DATA_PORT) & 0xf); outb(MSE_READ_X_HIGH, MSE_CONTROL_PORT); dx |= (inb(MSE_DATA_PORT) & 0xf) << 4;

* * * *

* * * * . . . . . . . * . . . .

1 . . 0 0 0 0 0

base + 2

index

dy buttons

Direct register . . . . . . . .

dx

10/8/10


SDU

47


outb(MSE_READ_X_LOW, MSE_CONTROL_PORT); dx = (inb(MSE_DATA_PORT) & 0xf); outb(MSE_READ_X_HIGH, MSE_CONTROL_PORT); dx |= (inb(MSE_DATA_PORT) & 0xf) << 4; ...

* * * * . . . .

* * * * . . . . . . . * . . . .

1 . . 0 0 0 0 0

base + 2

index

dx

dy buttons

Direct register

* * * * . . . .

base + 0

Register array

10/8/10 SCM'10 - Ulrik P Schultz, MMMI, SDU

48

SOLUTION

 Key observation:   Device drivers form a program family

 Approach:   Design a Domain-Specific Language (DSL)

 Expected benefits:   Performance: no performance penalty   Productivity: quantum leap in productivity   Robustness: increased robustness

10/8/10

9


49

IMPORTANT DSL CHARACTERISTICS  Performance: efficient compilation

  Appropriate abstractions   Language constructs designed to compile into efficient code

 Productivity: easier programming   Appropriate abstractions and notations   Declarative formulation: "What to do?" versus "How to do

it?"   Systematic re-use   Domain expertise captured

 Robustness: easier verification   Semantics can be restricted to make decidable some

properties that are critical to a domain   Separation of concepts to allow consistency verification

10/8/10


SDU

50

VISION Hardware vendor, Public repository,

Device expert

Device specification

•  High-level description of device interface •  Easy to write •  Strongly typed

Verifier

Compiler •  Consistency checking •  Code generation

Generated code

•  Functional interface •  Easy to use •  Debug/production mode

Driver

Driver programmer

Algorithmic

OS Interface

Device Interface


51

DOMAIN ANALYSIS: KEY CONCEPTS IDENTIFIED

 Port   Communication point   Different media: I/O, memory mapped

 Register   Repository of data in the device   indexed / paged, read / write, size, mask, …

 Variable   Collection of register fragments   Semantic value

10/8/10


SDU

52

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

base + 0

1 . . 0 0 0 0 0

base + 2

index

dx

dy buttons

Direct register

DEVIL BY EXAMPLE: MOUSE

Register array

10/8/10


SDU

53

... register index_reg = write base@2, mask ’1..00000’: bit[8];

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

base + 0

buttons

dx

dy

1 . . 0 0 0 0 0

base + 2 → index_reg

DIRECT ACCESS TO REGISTER

index Register array

10/8/10


SDU

54

... register index_reg = write base@2, mask ’1..00000’ : bit[8]; private variable index = index_reg[6..5] : int(2);

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

base + 0

1 . . 0 0 0 0 0


dx

dy buttons

PRIVATE VARIABLE

index Register array

10/8/10

10

10/8/10


SDU

55

... register index_reg = write base@2, mask ’1..00000’ : bit[8]; private variable index = index_reg[6..5] : int(2); ... register x_low = read base@0, pre {index = 0}, mask ’****....’ : bit[8]; register x_high = read base@0, pre {index = 1}, mask ’****....’ : bit[8]; ...

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

base + 0

→ x_low → x_high → y_low → y_high

1 . . 0 0 0 0 0


dx

dy buttons

INDEXED REGISTERS

index

10/8/10


SDU

56

... register index_reg = write base@2, mask ’1..00000’ : bit[8]; private variable index = index_reg[6..5] : int(2); ... register x_low = read base@0, pre {index = 0}, mask ’****....’ : bit[8]; register x_high = read base@0, pre {index = 1}, mask ’****....’ : bit[8]; ... variable dx = x_high[3..0] # x_low[3..0], volatile : signed int(8); variable dy = y_high[3..0] # y_low[3..0], volatile : signed int(8);

* * * * . . . . * * * * . . . . * * * * . . . . . . . * . . . .

base + 0

→ x_low → x_high → y_low → y_high

1 . . 0 0 0 0 0


dx

dy buttons

VARIABLES

index

10/8/10


SDU

57

outb(MSE_READ_X_LOW, MSE_CONTROL_PORT); dx = (inb(MSE_DATA_PORT) & 0xf); outb(MSE_READ_X_HIGH, MSE_CONTROL_PORT); dx |= (inb(MSE_DATA_PORT) & 0xf) << 4; outb(MSE_READ_Y_LOW, MSE_CONTROL_PORT ); dy = (inb(MSE_DATA_PORT) & 0xf); outb(MSE_READ_Y_HIGH, MSE_CONTROL_PORT); buttons = inb(MSE_DATA_PORT); dy |= (buttons & 0xf) << 4;

Existing code

COMPARISON

... variable dx = x_high[3..0] # x_low[3..0], volatile : signed int(8); variable dy = y_high[3..0] # y_low[3..0], volatile : signed int(8);

Devil


58

PERFORMANCE EVALUATION

 Experiments with three different devices:   Permedia2 X11 graphic controller   IDE disk controller   NE2000 compatible network controller

 No significant performance penalty (94% - 100%)


59

PRODUCTIVITY EVALUATION

 Difficult evaluation  Experience with 7 families of different devices for

the moment   Increasing robustness indirectly increases

productivity

10/8/10


SDU

60


Verifier

Consistency of Devil specifications •  No omission •  No double definition •  No overlapping •  Type/size of variables

THREE STEPS OF VERIFICATION

10/8/10

11

10/8/10


SDU

61


C compiler


Verifier

Compiler

Driver

Correct interface usage (type-checking)

Generated code

10/8/10


SDU

62


C compiler

Device driver


Generated code

Verifier

Compiler

Driver

Dynamic assertion checking


63

ROBUSTNESS EVALUATION

 Targeted programming errors :   Inattention error: confusion of names of identifiers   Typographical error: additional, missing or replaced

character in a literal constant

 Evaluation of the capacity to detect a programming error at CT or RT

 Emulation of errors based on mutation analysis


64

DEVIL SUMMARY

 Language dedicated to the specification of device programming interface

 Realizes DSL benefits :   Performance: no significant performance penalty   Productivity: quantum leap in productivity   Robustness: increased robustness

 Challenges in domain adoption:   cost of maintenance   general unwillingness to use complex tools

SOFTWARE ENGINEERING FOR MODULAR ROBOTS

CONTEXT: [MODULAR] SELF-RECONFIGURABLE ROBOTS

 Whole composed of physically connected modules   Real-time distributed

embedded system   Physical composition

influences behavior

 Module typically has several distinct behaviors

 Stable vs. continuous configuration

10/8/10 S

CM

'10 - Ulrik P

Sch

ultz, M

MM

I, SD

U

66

M-TRAN

Odin (deformable)

ATRON

10/8/10

12

PROBLEM: CONTROLLER PROGRAMMING FOR MODULAR ROBOTS

 Challenges:   distributed real-time system with limited

computational resources and dynamically evolving network topology

  scalability to large and complex shapes requires abstraction over the concrete structure

 Existing approaches:   algorithmic: metamodules, motion planning, rule-

based programming (plus many ad-hoc solutions)   reusable HAL but one-shot C programs for control   (fragile) communication in terms of explicit

communication ports (sensitive to physical orientation)

 Abstraction?

10/8/10

67

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

STEP#1: ROBUST EMBEDDED PROGRAMMING USING NESC

 TinyOS+nesC developed for sensor networks; we hypothesize it is also useful for robots

 Explicit event-driven concurrency model, communication infrastructure

 Steep learning curve (no silver bullet)

10/8/10 S

CM

'10 - Ulrik P

Sch

ultz, M

MM

I, SD

U

68

event message_t* Receive.recv(...) { if (rcvdMsg->info == START) { if (!reconfigurationStarted) post startReconfiguration(); } ... } task void startReconfiguration() { reconfigurationStarted = TRUE; call Conn4.retract(); call Conn6.retract(); } event void Conn4.retractDone(...) { ... }

Empirical? •  Ideally: compare size, robustness, performance etc to previous •  In practice: report on size and enabled experiments

STEP#2: PROGRAMMING LANGUAGE ABSTRACTIONS FOR ROLES AND STRUCTURE

69

role Head {! #connections(*)==2;! handle proximity(C3) {! LeftWheel.reverse()! ...! }!}!role LeftWheel {! #connections(WEST)==0;!}!role RightWheel {! #connections(EAST)==0;!}!

virtual connector ID, independent of module rotation

Role: set of behaviors that are active in a given context

N

S

W

E U

D

DynaRole

[APGES’07,ICRA’09]

compass directions propagated from “seed” module

10/8/10 S

CM

'10 - Ulrik P

Sch

ultz, M

MM

I, SD

U

Empirical? •  Ideally: compare size, robustness, performance etc to previous & others •  In practice: report on size and simplicity

STEP#3: VM

DynaRole (previous slide)   Declarative specification

of role selection   Compiles to DCD-VM

program fragments

DCD-VM   Dynamic code

distribution:   role-based code diffusion   runtime, non-intrusive

  Context management (neighbors + compass & 3D position from seed)

  Role-based behavior control & scheduling

  Role-based group communication

70 [RoboComm’07,ICRA’09]

10/8/10 S

CM

'10 - Ulrik P

Sch

ultz, M

MM

I, SD

U

Empirical? •  Ideally: compare size, robustness, performance etc to previous & others •  In practice: report on reprogramming time and size

STEP#4: SCRIPTING OF GROUP BEHAVIOR

  Specify group behavior as parallel sequence of actions   identify modules by roles

  Reversible actions imply reversible group behavior   sequence is a DAG   reverse DAG and each

node to reverse program

  Efficient and robust state propagation

  Needs more general control structures

10/8/10 S

CM

'10 - Ulrik P

Sch

ultz, M

MM

I, SD

U

71 X3

seq eight2car = { M1.connector[4].retract() | M2.connector[2].retract() ; M0.rotateFromToBy(...); ... } seq car2eight = rev eight2car;

[IROS’09]

Empirical? •  Ideally: compare size, robustness, performance etc to previous & others •  In practice: simulated experiments on ATRON

STEP#5: GENERALIZATION

10/8/10 S

CM

'10 - Ulrik P

Sch

ultz, M

MM

I, SD

U

72

 Problem: ATRON-specific abstractions

 Solution: tools and languages for arbitrary reconfigurable mechatronic structure

 Concretely: M3L   declarative shape

description   computes math   generates code

ATRON.M3L

physics-based simulation

DCD-VM kinematics

DynaRole spatial concepts

MTRAN.M3L

Molecubes.M3L

M3L compiler

WEST=... center=...

Empirical? •  Ideally: compare size, robustness, performance etc to specific •  In practice: simulated experiments

10/8/10

13

ANALYSIS

 Domain: modular robots   potentially very useful technology   currently very difficult to work with

 Main point: programming languages approach   provide immediate benefits to the developer   lift level of abstraction for the programmer

 The story: NesC, VM, DynaRole, M3L  Assessment (empirical work):

  so far mostly demonstrators (domain as a whole)   control experiments should be used, both for same

family of robots and for other types   USSR+M3L has potential (fidelity an issue)

10/8/10

73

SC

M'10 - U

lrik P S

chu

ltz, MM

MI, S

DU

lecture 06 08102010 empirical software -...

Documents

Transcript of lecture 06 08102010 empirical software -...