Apeldoorn It 2008 - Adaptiviteit In Software Architectuur
•Download as ZIP, PDF•
0 likes•415 views
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?
Recommended
More Related Content
Similar to Apeldoorn It 2008 - Adaptiviteit In Software Architectuur
Similar to Apeldoorn It 2008 - Adaptiviteit In Software Architectuur (20)
Recently uploaded
Recently uploaded (20)
Apeldoorn It 2008 - Adaptiviteit In Software Architectuur
- 1. “Great designs come from great designers” - F. P. Brooks Adaptivity in Software Architecture
- 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. 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. Adaptivity in Software Architecture luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 4
- 5. Associations • Robustness • Intelligence • Scalability • Flexibility • Autonomy luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 5
- 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. 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. Emergence www.robbaker.org http://en.wikipedia.org/wiki/Internet luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 7
- 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. 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. 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. Parallelizability & Distributability • Some trends • Multi-core systems • Mobile equipment • Increased networking luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 11
- 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. Adaptivity in Software Architecture luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 13
- 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. From concept to architecture luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
- 17. From concept to architecture Style Architecture Concept luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
- 18. From concept to architecture Quality factor Style Architecture Concept Artifact luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 15
- 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. 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. Adaptivity in Software Architecture luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 17
- 22. Whoops... • Concepts... • capture intuition, and • are ‘recognizable’ luminis® 2008 - Adaptivity in Software Architecture - Angelo van der Sijpt 18
- 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. 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. 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. 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. 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. 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
Editor's Notes
- 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.