“Great designs come from great designers” - F. P. Brooks




Adaptivity in Software Architecture
Who?
• Angelo van der Sijpt
     • Software engineer
     • Fontys Eindhoven, Computer Science, 2003
     • TU Eindhoven, ...
Who?
• luminis
     • 25 employees
     • Arnhem, Enschede
     • Innovative software
     • In-house and at customer
    ...
Adaptivity
                    in
                    Software Architecture



luminis® 2008 - Adaptivity in Software Arch...
Associations
•   Robustness
•   Intelligence
•   Scalability
•   Flexibility
•   Autonomy




luminis® 2008 - Adaptivity i...
What is adaptivity?
• “Any sufficiently advanced technology is
  indistinguishable from magic.” –Arthur C. Clarke




lumi...
What is adaptivity?
• “Any sufficiently advanced technology is
  indistinguishable from magic.” –Arthur C. Clarke
• Adapti...
Emergence




www.robbaker.org

                                                   http://en.wikipedia.org/wiki/Internet

...
Redundancy
• What?
     • Making elements expendable


• Current examples
     • P2P systems, backups, RAID


• Issues
   ...
Decoupling
• Localizing effects
• “Something has to give”




                                                http://flickr...
Service awareness
• Everything is a resource
     • Use when available, cope when not


• Trading, e.g.
     • correctness...
Parallelizability & Distributability
• Some trends
     • Multi-core systems
     • Mobile equipment
     • Increased netw...
Scalability




                                                               Qu
                                        ...
Adaptivity
                    in
                    Software Architecture



luminis® 2008 - Adaptivity in Software Arch...
A concept
• What exactly is a concept?
     • A fundamental choice of focus
     • Could be a choice of technology, but un...
From concept to architecture




luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt   15
From concept to architecture




                                                                             Style
      ...
From concept to architecture
                          Quality factor




                                                ...
From concept to architecture
                          Quality factor                                             Nonfunct...
Adaptivity and software architecture?
• Useful styles
     • Event based
     • P2P
     • SOA


• Measurable by concepts,...
Adaptivity
                    in
                    Software Architecture



luminis® 2008 - Adaptivity in Software Arch...
Whoops...
• Concepts...
     • capture intuition, and
     • are ‘recognizable’




luminis® 2008 - Adaptivity in Software...
Whoops...
• Concepts...
     • capture intuition, and
     • are ‘recognizable’


• But...
     • are not ‘creatable’, and...
Yes, there is a problem
• There are no fool-proof methods
• Still, there are many projects that end more or
  less satisfa...
Yes, there is a problem
• There are no fool-proof methods
• Still, there are many projects that end more or
  less satisfa...
Any advice?
• Continue progress, but do not look for a silver
  bullet.
• Be aware of oversimplification. Creating good
  s...
In the end

• Flexible, adaptive software needs a new way of
  making it.




luminis® 2008 - Adaptivity in Software Archi...
Angelo van der Sijpt
                       angelo.vandersijpt@luminis.nl

   “Adaptivity in Software Architecture”, TU/e,...
Upcoming SlideShare
Loading in...5
×

Apeldoorn It 2008 - Adaptiviteit In Software Architectuur

385

Published on

At Apeldoorn IT 08, I fell in for our CEO to deliver a talk on adaptivity in software architecture. Oh, wasn't my graduation assignment about that?

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
385
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
  • Gee, hey, welcome. What do you expect this workshop will be about?



    Oh, and please do interrupt me.



    About this presentation: I want to look at adaptivity from a number of angles, show the six concepts written up recently, and arrive show that concepts as these are valid ‘input’ for an architecture process. Finally, this examples shows that the current ways of creating software might very well be the wrong ones.
    This presentation is roughly based on ‘An engineer is not a carpenter’ and ‘Architecting adaptive software’
  • Any Associations? (It is not about adapting an architecture, it is about catching adaptive behavior in a system’s architecture. No, architecture does not change.)
  • Adaptivity leads to visions of autonomous robots that ‘do their own thing’ in a self sufficient way. Hardware is, of course, important, but we are reaching the limits of the complexity of software we can handle.



    Example: IP routing. It is in essence very simple, but it displays seemingly intelligent behavior. This is all by design, but not from its architecture.
  • Basically, adaptivity is something we can recognize, but cannot point out or engineer; it does not really exist, but is an artifact of other concepts.



    Coming next: those concepts!
  • Basically, adaptivity is something we can recognize, but cannot point out or engineer; it does not really exist, but is an artifact of other concepts.



    Coming next: those concepts!
  • Left: Safari ants. Soldiers create a tunnel for other ants to pass under when the colony migrates.
    Right: Partial internet topology, 2005
    Binding: noone is ‘the boss’
    Even simple combined behavior gets way over our head.
    ‘sufficient complexity’ & ‘balance in rules’
  • Ring of uselessness. In stead, we should not be interested in adding superfluous components, but how to make components in such a way that the can be superfluous
    Technology has some nice examples, but so does nature (species) and society (culture).
    However, we could lose determinism.
  • Stuff that breaks is not bad. Stuff that breaks and breaks the system, is.
    We want to localize the effect: analogy of a guitar string.
    Interfaces as a part of OO are a step in the right direction, but they try to localize effects in a single component.
  • Examples: Google news, audio system



    Coping with changes in the available services a basic component of service frameworks; however, it can easily be misused.
  • Together, these trends lead to many sort-of isolated elements of calculation, which we might want to work together.
    (Vision: only use processing power when we really need it, and adopt it to our surroundings when not)
    (IBM stated in the 50’s that there would be a world market for 5 computers. It might even be 1.)
  • Redundancy allows us to make systems either more reliable, or bigger, or cheaper. Ideally, we want to be able to trade these. We saw something similar in resource consumption.
    Combination of other concepts, but that also means that it could be harder to create.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Bottomline: we use concepts as binding and defining entities.
    Concepts are the core, those fundamental focus points and choices. A set of concepts can form an architecture, but also a style; architectural styles are sets of concepts which have proven to work together well, or at least have known properties.
    Artifacts embody the architecture. Creating ‘good’ artifacts is a matter of alignment.
    Both architectures and styles can display quality factors (‘ilities’). For styles, these are ‘knowns’, for architectures, they are measured.
    Finally, artifacts together make up a system, which displays non-functional properties (even more ilities).
    Interesting: what is the link between concepts and quality factors, and between quality factors and non-functionals.
  • Guess what, those are fashionable styles!
  • We don’t want to go from small to large,but the other way around! We don’t want unpredictability!
    - Formalization doesn’t cut it
    - An engineer is not a carpenter
    - Software is not wood, and the engineer is not the ‘worker’
    - Is software engineering really engineering?
  • We don’t want to go from small to large,but the other way around! We don’t want unpredictability!
    - Formalization doesn’t cut it
    - An engineer is not a carpenter
    - Software is not wood, and the engineer is not the ‘worker’
    - Is software engineering really engineering?
  • We don’t want to go from small to large,but the other way around! We don’t want unpredictability!
    - Formalization doesn’t cut it
    - An engineer is not a carpenter
    - Software is not wood, and the engineer is not the ‘worker’
    - Is software engineering really engineering?
  • Wickedness: describing the problem is the problem, no stopping rule, one-shot
  • Wickedness: describing the problem is the problem, no stopping rule, one-shot
  • Wickedness: describing the problem is the problem, no stopping rule, one-shot
  • Wickedness: describing the problem is the problem, no stopping rule, one-shot
  • Trust those good people. give them room, and do not think they are expendable and replaceable.
  • Apeldoorn It 2008 - Adaptiviteit In Software Architectuur

    1. 1. “Great designs come from great designers” - F. P. Brooks Adaptivity in Software Architecture
    2. 2. Who? • Angelo van der Sijpt • Software engineer • Fontys Eindhoven, Computer Science, 2003 • TU Eindhoven, Computer Science and Engineering, 2007 luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 2
    3. 3. Who? • luminis • 25 employees • Arnhem, Enschede • Innovative software • In-house and at customer • Share knowledge luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 3
    4. 4. Adaptivity in Software Architecture luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 4
    5. 5. Associations • Robustness • Intelligence • Scalability • Flexibility • Autonomy luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 5
    6. 6. What is adaptivity? • “Any sufficiently advanced technology is indistinguishable from magic.” –Arthur C. Clarke luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 6
    7. 7. What is adaptivity? • “Any sufficiently advanced technology is indistinguishable from magic.” –Arthur C. Clarke • Adaptivity is • Something we ‘know when we see it’ • But we cannot point it out • Something desirable luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 6
    8. 8. Emergence www.robbaker.org http://en.wikipedia.org/wiki/Internet luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 7
    9. 9. Redundancy • What? • Making elements expendable • Current examples • P2P systems, backups, RAID • Issues • No guarantees • How to shut down? luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 8
    10. 10. Decoupling • Localizing effects • “Something has to give” http://flickr.com/photos/33006928@N00/32979973/ luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 9
    11. 11. Service awareness • Everything is a resource • Use when available, cope when not • Trading, e.g. • correctness for reliability • quality for availability luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 10
    12. 12. Parallelizability & Distributability • Some trends • Multi-core systems • Mobile equipment • Increased networking luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 11
    13. 13. Scalability Qu ce ali an ty orm of se rf Pe rvi ce Resource consumption luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 12
    14. 14. Adaptivity in Software Architecture luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 13
    15. 15. A concept • What exactly is a concept? • A fundamental choice of focus • Could be a choice of technology, but underlying this is likely something else. • We can bind concepts together to form styles, • or to form architectures luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 14
    16. 16. From concept to architecture luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
    17. 17. From concept to architecture Style Architecture Concept luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
    18. 18. From concept to architecture Quality factor Style Architecture Concept Artifact luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
    19. 19. From concept to architecture Quality factor Nonfunctional Style Architecture Concept Artifact System luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
    20. 20. Adaptivity and software architecture? • Useful styles • Event based • P2P • SOA • Measurable by concepts, but corresponding with intuition luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 16
    21. 21. Adaptivity in Software Architecture luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 17
    22. 22. Whoops... • Concepts... • capture intuition, and • are ‘recognizable’ luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 18
    23. 23. Whoops... • Concepts... • capture intuition, and • are ‘recognizable’ • But... • are not ‘creatable’, and • do not correspond to methods luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 18
    24. 24. Yes, there is a problem • There are no fool-proof methods • Still, there are many projects that end more or less satisfactory. Why? luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 19
    25. 25. Yes, there is a problem • There are no fool-proof methods • Still, there are many projects that end more or less satisfactory. Why? • People luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 19
    26. 26. Any advice? • Continue progress, but do not look for a silver bullet. • Be aware of oversimplification. Creating good software is hard. • Trust good people! luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 20
    27. 27. In the end • Flexible, adaptive software needs a new way of making it. luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 21
    28. 28. Angelo van der Sijpt angelo.vandersijpt@luminis.nl “Adaptivity in Software Architecture”, TU/e, 2007 tue.nl/bibliotheek luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 22
    1. A particular slide catching your eye?

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

    ×