modeling: the holy grail for designing complex systems?
DESCRIPTION
presentation given at the ESI Symposium 2009 (Eindhoven, The Netherlands); abstract: http://www.esi.nl/events/esi_symposium_2009/programme/2_1_abstract.htmlTRANSCRIPT
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