0
Modeling: the holy grail for designing
                   complex systems?




                               Teade Punter...
Aspects of reality


• Multiple formalisms are needed to answer specific
  questions
     • Typical problem: Not feasible ...
Aspects of reality


• Concurrent engineering
     • Typical problem: Not keeping track of design decisions

     • Typica...
Aspects of reality


• Not feasible to model the complete system
     • Typical problem: It is not cost effective to model...
Belief


     IDEAL                    CURRENT
    FUTURE                     REALITY


                          MAKING  ...
Design methodology for high-tech systems

   the world

                                                                  ...
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
             » ...
Integration Framework basic blocks


• Model:
      • From “drawing on a napkin” to
        “model to model transformation...
Integration Framework basic blocks


• View:
      • Representation of an aspect at
        system level
      • System de...
Integration Framework basic blocks


• Design flow:                                   design option
                      ...
Prototype DSL




     13
Prototype DSL: textual editor




             14
Integration Framework features


• Populating
  dependencies
       • One or multiple
         views


• Conflict detectio...
Prototype VIEW: graphical editor




BASIC   BLOCK




                        ADD   PROPERTY  / MODEL
                   ...
Prototype VIEW: graphical editor




                              PROPERTY   HAS
VALUE, UNIT

     RANGE

DEPENDENCY
    ...
Integration Framework features


                                                                                         ...
More features


• Decision tree and impact of design decisions

• Design process as a time-based graph

• Statistics per v...
What the Integration Framework is?




            • Be invisible and seamless
            • Support the typical activitie...
Summary


• Strengths: “Making the implicit explicit  bridging the gap”
   – Know the exact implication of each design de...
Modeling: the holy grail for designing complex
                  systems!




                        flow


             ...
Thank you for your attention!




              23
Upcoming SlideShare
Loading in...5
×

Modeling: the holy grail for designing complex systems?

350

Published on

presentation given at the ESI Symposium 2009 (Eindhoven, The Netherlands); abstract: http://www.esi.nl/events/esi_symposium_2009/programme/2_1_abstract.html

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
350
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Modeling: the holy grail for designing complex systems?"

  1. 1. Modeling: the holy grail for designing complex systems? Teade Punter (ESI) Roelof Hamberg (ESI) Hristina Moneva (ESI)
  2. 2. Aspects of reality • 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? 2
  3. 3. 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
  4. 4. 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
  5. 5. Belief IDEAL CURRENT FUTURE REALITY MAKING THE IMPLICIT EARLY FLAW EXPLICIT  BRIDGING DETECTION THE GAP!!! MAINTAIN DESIGN CONCURRENT CONSISTENCY ENGINEERING IMPROVED DESIGN MULTIPLE QUALITY FORMALISMS NOT FEASIBLE TO SHORTENINGOVERALL MODEL THE COMPLETE DESIGN PROCESS SYSTEM 5
  6. 6. Design methodology for high-tech systems the world Preparation market opportunity drivers identify key drivers critical realization & requirements aspects State of technological opportunity changes the Art realization options key requirements consolidate data, models, experience core domain changes know-how rules, models, no-brainers data, solutions Selection of critical aspects questions Evaluation of design options explanation open identify questions gather facts & build small perform tensions and uncertainties models measurements conflicts answers verification decisions decisions Design specifications Record Design decisions 6 07/12/200
  7. 7. Modeling: the holy grail for designing complex systems? 7
  8. 8. Requirements for Integration Framework 8
  9. 9. 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
  10. 10. Integration Framework basic blocks • Model: • From “drawing on a napkin” to “model to model transformations” • May be part of multiple components / views formalism accuracy credibility • May be used for analysis working range • Parameters: structure/abstraction • May have range, type, unit facts model decision taking OUTPUT INPUT • Represent: errors assumption verification unknown measurements analysis specification » Assumptions uncertainties » Measurements » Requirements tool tool tool tool » Etc. • May have dependencies 10
  11. 11. Integration Framework basic blocks • View: • Representation of an aspect at system level • System decomposition & parameter environment VIEW dependencies system • Multiple models per component • Multiple experiments per model • Design step: M M • Multiple views M M • Hierarchy of components M M • Multiple models per component • Completeness of modeling: • “Boderc” • ~10% 11
  12. 12. Integration Framework basic blocks • Design flow: design option design option • Decisions DS design decision DS – Design decision design option assure/predict – Design options (alternatives) qualities • Refinement • Process independent: • Keeps track of design decisions • Provides model / result management DS DD DS DD DD DS DS DD DS DD DS DD DS DS – design step DD – design decision 12
  13. 13. Prototype DSL 13
  14. 14. Prototype DSL: textual editor 14
  15. 15. Integration Framework features • Populating dependencies • One or multiple views • Conflict detection • One or multiple views • In previous design step 15
  16. 16. Prototype VIEW: graphical editor BASIC BLOCK ADD PROPERTY / MODEL ONLY IF NEEDED! 16
  17. 17. Prototype VIEW: graphical editor PROPERTY HAS VALUE, UNIT RANGE DEPENDENCY MODEL HAS FILE EXPERIMENT CONFLICT DETECTION 17
  18. 18. Integration Framework features DD1: add ... DD2: continue DS0 DS1 (iteration 1) developing... • Multi-user (team) design process DS0 DD1 DS1 DD2 DS2 DO1 • Reuse of components DD3 DS3 DD4 DS4 DO2 Team A DS0 DD1 DS1 DD2 DS2 Team B PRODUCT NEW DD1: add “System A” DD2: continue DS0 DD1 DS1 DD2 DS2 DS0 DS1 as component developing... DD3 DS3 DD4 DS4 re us e Team C BRANCH MERGE REUSED COMPONENT DS2 DD2 DS0 DD1 DS1 DD3 DO1 DS3 DD4 DS4 DD5 DS5 DO2 DO3 System A 18
  19. 19. 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
  20. 20. What the Integration Framework is? • Be invisible and seamless • Support the typical activities SHOULD • Provide help • Restrict process choice • Restrict tool choice SHOULD • Restrict formalism choice NOT 20
  21. 21. 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
  22. 22. Modeling: the holy grail for designing complex systems! flow view model What did we miss? 22
  23. 23. Thank you for your attention! 23
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×