Modeling: the holy grail for designing complex systems?

Modeling: the holy grail for designing complex systems?

Teade Punter (ESI)Roelof Hamberg (ESI)Hristina Moneva (ESI)

Aspects of reality

2

• Multiple formalisms are needed to answer specific questions

• Typical problem: Not feasible to model the complete system

• Typical problem: Not all users have the latest version of the system

• Typical problem: What are the implications to the rest of the system

• How to connect these tools / models in generic way and provide early flaw detection?

Aspects of reality

• Concurrent engineering

• Typical problem: Not keeping track of design decisions

• Typical problem: Not explicit enough to the rest of the team

• Typical problem: What are the implications to the rest of the system => which components are affected

• Typical problem: Forget to re-run some experiments => not consistent results

• How to provide model and result history related to the design decisions taken?

3

Aspects of reality

• Not feasible to model the complete system

• Typical problem: It is not cost effective to model the complete system

• Boderc: only ~10% of the system is being modeled

• How to connect models which cover different parts of the same system?

4

IDEALFUTURE

CURRENTREALITY

NOT FEASIBLE TOMODEL THE COMPLETE

SYSTEM

MULTIPLEFORMALISMS

CONCURRENTENGINEERING

MAKING THE IMPLICITEXPLICIT BRIDGING

THE GAP!!!

SHORTENING OVERALLDESIGN PROCESS

IMPROVED DESIGNQUALITY

MAINTAIN DESIGNCONSISTENCY

EARLY FLAWDETECTION

Belief

5

Design methodology for high-tech systems

607/12/200

decisions

State ofthe Art

market opportunity

Design specifications Record Design decisions

rules, models,data, solutions

questions

chan

ges

consolidatecore domainknow-how

answersch

anges

data, models, experience

the worldno-

bra

iner

s

Preparation

driversidentify key drivers& requirements

critical realizationaspects

Selection of critical aspects

identifytensions and

conflicts

openquestions gather facts &

uncertainties

key

requir

emen

tsre

aliz

atio

n o

ption

s

decisions

Evaluation of design options

build smallmodels

performmeasurements

explanation

verification

technologicalopportunity

Modeling: the holy grail for designing complex systems?

7

Requirements for Integration Framework

8

Integration Framework overview

• Basic concepts and assumptions:• Design flow• Design step

» View» Components» Model

• Design decision

• Integration Framework should support:

• Basic element representation• Populating dependencies• Conflict detection• Design process representation

9

Integration Framework basic blocks

• Model:• From “drawing on a napkin” to

“model to model transformations”• May be part of multiple components /

views• May be used for analysis

• Parameters:• May have range, type, unit• Represent:

» Assumptions» Measurements» Requirements» Etc.

• May have dependencies

10

model

analysis

facts

assumption

measurements

decision taking

structure/abstraction

errorsunknownuncertainties

formalism

tool tool tool tool

verification

specification

accuracycredibilityworking range

INPU

T

OU

TPUT

Integration Framework basic blocks

• View:• Representation of an aspect at

system level• System decomposition & parameter

dependencies• Multiple models per component• Multiple experiments per model

• Design step:• Multiple views• Hierarchy of components• Multiple models per component

• Completeness of modeling:• “Boderc”• ~10%

11

environment

system

VIEW

M

M

M

MM

M

Integration Framework basic blocks

• Design flow:• Decisions

– Design decision– Design options (alternatives)

• Refinement

• Process independent:• Keeps track of design decisions• Provides model / result management

12

DS DSdesign decision

design option

design optiondesign option

assure/predictqualities

DS

DS

DS

DS

DS DS DS

DD

DD

DD

DD

DD DD

DS – design stepDD – design decision

Prototype DSL

13

Prototype DSL: textual editor

14

Integration Framework features

• Populating dependencies

• One or multiple views

• Conflict detection• One or multiple

views

• In previous design step

15

Prototype VIEW: graphical editor

16

BASIC BLOCK

ADD PROPERTY / MODELONLY IF NEEDED!

Prototype VIEW: graphical editor

17

VALUE, UNITPROPERTY HAS

RANGE

DEPENDENCY

FILEMODEL HAS

EXPERIMENT CONFLICT DETECTION

Integration Framework features

• Multi-user (team) design process

• Reuse of components

18

Team A

Team B

Team C

DS0 DS1 DS2DD1 DD2

DD3 DD4DO1

DO2DS3 DS4

DS0 DS1DD1

DD2 DS2

DS0 DS1 DS2DD1 DD2

DD4DS3 DS4DD3

DS0 DS1DD1: add ...(iteration 1)

DD2: continuedeveloping...

BRANCH MERGE

DS0 DS1

DS2

DS5

DD1DD2

DD3

DD4 DD5DO1

DO2DO3

DS3 DS4

DS0 DS1DD1: add “System A” as component

System A

DD2: continuedeveloping...

NE

W

PR

OD

UC

TR

EU

SE

D C

OM

PO

NE

NT

reuse

More features

• Decision tree and impact of design decisions

• Design process as a time-based graph

• Statistics per view, component, user

• Domain tailoring for process and views as well as glossaries, taxonomies, and domain-specific phenomena

• Relationship-based exploration or cause-effect analysis

19

What the Integration Framework is?

20

SHOULD

• Be invisible and seamless• Support the typical activities• Provide help

SHOULD NOT

• Restrict process choice• Restrict tool choice• Restrict formalism choice

Summary

• Strengths: “Making the implicit explicit bridging the gap”– Know the exact implication of each design decision– Reuse models (resume from previous design steps, do not start from

the scratch)– Continuous integration at model/design level (not only during

realization)– Keep dependencies in control

• Dealing with heterogeneous models• Continuous conflict detection

– Better / easier communication within design team

• Weaknesses:– Too generic approach (does not support concrete methods and tools)– Requires discipline and introduces overhead– Introduces other way of working

21

Modeling: the holy grail for designing complex systems!

model

view

flow

22

What did we miss?

Thank you for your attention!

23