Fundamentals Of Software Architecture

20,682 views
16,754 views

Published on

Software development is a very dynamic discipline, it can be very hype-driven at times. Technologies change all the time. For years, the pattern movement has successfully aimed at capturing the essence of what’s going on in the software development field in order to make sure wheels are not invented over and over again. Some patterns are very specialized, some are quite fundamental (such as the GoF patterns).
However, what are really the fundamentals of software development? Quicksort? Scheme? UML? What would you like all your developers in the team to really understand, what would you like to be the guiding principles of a curriculum of software engineering?
In this pattern language, I try to capture these principles. I will illustrate them with quite different, but usually contemporary and relevant technology examples. Some of the principles are implemented in languages, others in technologies, some in processes.

Published in: Technology, Business
3 Comments
68 Likes
Statistics
Notes
  • Why it does not have download option
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • A refresher for software archirecture, since I am busy too much on details.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • This presentation tells about nothing. Key questions are not answered - what is SA? What are the tools? What tasks you`re engaged with?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
20,682
On SlideShare
0
From Embeds
0
Number of Embeds
791
Actions
Shares
0
Downloads
0
Comments
3
Likes
68
Embeds 0
No embeds

No notes for slide

Fundamentals Of Software Architecture

  1. Fundamentalsof Software Architecture<br />Lookingbeyondthehype<br />MarkusVölter<br />(voelter@acm.org)<br />
  2. 1<br />Introduction<br />
  3. Frustratedbyall thehype?<br />Frustrated by all the hype?<br />
  4. If sothispresentationisforyou.<br />
  5. Otherwiseyoushouldleave<br />
  6. People oftentalk abouttechnologiesinsteadofarchitecturalconcepts.<br />
  7. Technology-discussionscreate a lotofaccidentalcomplexity.<br />
  8. Architecturalessenceishiddenbehindtechgobbledygook<br />
  9. Conceptschangemuch<br />More slowlythanthe<br />Hype-driventechno<br />marketing<br />
  10. Thispresentation:<br />Thispresentation:<br />Timeless<br />concepts<br />
  11. Thispresentation:<br />Thispresentation:<br />Relationships<br />betweenthem<br />
  12. Thispresentation:<br />Thispresentation:<br />Exampleslanguages<br />architecture<br />technology<br />
  13. awarenesswhenbuildingsystems<br />Goals<br />
  14. checklistsforreviewingsystems<br />Goals <br />
  15. educationofdevelopersandarchitects<br />Goals <br />
  16. ConceptsAtomicCombinable Technology NeutralDescribableNamed (Patterns, Laws, Principles)<br />
  17. CombinatorsB ! A B  A BA <br />
  18. Ok, let‘sgo…<br />Ok, let‘sgo…<br />
  19. 2<br />Breaking Things Down<br />
  20. Modularize<br />Procedures, Classes, Components, Services, User Stories<br />
  21. ! Modularize<br />Encapsulate<br />Private Members<br />Frameworks <br />Facade Pattern <br />Components<br />Layers/Rings/Levels<br />Packed Data Wrapper<br />
  22. ! Modularize<br />Contracts<br />Interfaces<br />Pre/Post Conditions <br />Protocol State Machines <br />Message Exchange Patterns<br />Published APIs<br />
  23. Decoupling<br />CompensatingTx<br />Message Queues<br />! Modularization<br />
  24.  Modularize<br />Handle<br />Crosscuts<br />Aspect Orientation<br />Interceptors<br />Application Servers<br />Exception Handling<br />
  25. Go Down<br />Encapsulate<br /> ! Modularize<br />Assembler in C<br />C in Python/Ruby<br />SQL in Java<br />
  26. Isolate<br />Pure functional vs. Impure<br />Safety Critical Parts<br />Real-Time Kernel<br />OS Processes<br /> ! Modularize<br />
  27. IsolateTechnology<br /> ! Modularize<br /> Isolate<br />POJOs<br />HALs<br />JBI/SCA<br />Code Gen/MDSD<br />
  28. 3<br />Scalingthingsup<br />
  29. Parametrization<br />Function Arguments<br />Command-Line Args<br />Configuration Files<br />! Modularization<br />
  30. Simplicity<br />Web<br />Lisp<br />XML<br />
  31. Decentralization<br />! Contracts<br />EmergentBehaviour<br />The Internet<br />Service-OrientedArchitecture<br />
  32. Bootstrapping<br />Languages<br />Compilers<br />IDEs<br />
  33. Standard <br />Library<br />Lisp (Grow A Language)<br />AutosarSysComponentsMicrokernel OSs<br />! Modularize<br />! Types & Instances<br />
  34. Orthogonality<br />Closures, Program As Data,<br />Macros, Higher-Order Functions<br />
  35. Identity<br />Pointers<br />GUIDs<br />MAC-Address<br />URI<br />QualifiedNames<br />
  36. 4<br />Conceptualization<br />
  37. Abstraction<br />Operating Systems<br />High-Level Languages<br />Models, DSLs<br />
  38. Types & Instances<br />ProgrammingLanguages<br />Components<br />Models & Metamodels<br />RDBMS/XML Schemas<br />
  39. Hierarchical<br />Decomposition<br /> Modularize<br />Procedures/Methods<br />State Machines, Components<br />
  40. Specialize<br />Currying<br />Inheritance<br />State Machines<br />
  41. ! Abstraction<br />Formalize<br />Languages<br />Contracts<br />Models<br />State Machines<br />
  42. Viewpoints<br />! Formalization<br />Configuration Files<br />4+1 Model<br />Blackbox/Whitebox<br />Types/Instances/Deployment<br />
  43. ! Formalization<br />Notation<br />UML<br />Lisp<br />Java<br />Ruby<br />
  44. ! Modularize<br />Go Meta<br />Translators, Reflection, <br />Meta Programming, AOP<br />
  45. Reflection<br />! Go Meta<br />Languages (Lisp, Smalltalk, Ruby)<br />Embedded Systems (Static)<br />
  46. ! Formalization<br /> ! Go Meta<br />Translate<br />Compilers, Transformers, Generators,<br />Macros (Lisp, Converge)<br />
  47. ! Formalization<br /> ! Go Meta<br />Formalize<br />Interpret<br />Business Process Engines<br />Data Driven Systems<br />(Dynamic) Languages<br />
  48. Tracking<br />Impurity in Haskell: io(…)<br />Tainting (Static Analysis)<br />Session State<br />ACT Pattern<br />
  49. Automate<br />Build, Test, Translate<br />! Formalization<br />
  50. 5<br />DosandDon‘ts<br />
  51. ! Formalization<br />Protocols<br />Transctions<br />Locking/Synchronization<br />Resource Access<br />
  52. Make Explicit<br />DOC Middleware<br />Orthogonal Persistence<br />(OR Mappers)<br />DOC Middleware<br />Orthogonal Persistence<br />(OR Mappers)<br />Make<br />Transparent<br />
  53. Make Transparent<br />Make Explicit<br />Dependencies<br />SOA, Messaging<br />FunctionalProgramming<br />PLE Variabilities<br />Persistence: Loading Data<br />
  54. Software Architecture<br />DSL: expressiveness<br />MDSD: skeletons<br />Scade/SystemC<br />LimitFreedom<br />
  55. ! Formalization<br /> ! Go Meta<br />Declaration<br />Implementation<br />App Servers (EJB), Plugin RT (Eclipse)<br />Models, TransaactionalMemory<br />
  56. Test semantics, not syntax (code gen)<br />Higher Order Functions (map, foreach)<br />Transactional Memory<br />Don‘t<br />Overspecify<br />
  57.  Limit Freedom<br />AvoidSideeffects<br />FunctionalProgramming<br />Concurrency (Sharing)<br />Distribution<br />
  58. 6<br />Process<br />
  59. Iterate<br />Algorithms<br />Refactoring<br />Agile Processes<br />
  60. Capture<br />Best Practices<br />Patterns, DSLs, Models, Translators<br />
  61. More I<br />Ownership vs. Reference<br />BuildLanguages<br />CohesionandCoupling (do onethingright, composability)<br />Indirection (polymorphism, memreferencesforcompaction, namingservice)<br />Prevention vs. Compensation<br />
  62. More II<br />BuildPlatforms<br />Versioning<br />Pessimistic/Optimistic/Compensating<br />Localize (Sync in MP, UML-M2M)<br />Container (AppServer)<br />Lazy/On-demand, Eager<br />SelfModification (MetaProg, MOPs, Embedded Optimization<br />Measure: metrics, performance tuning, scalability, test coverage<br />
  63. What do youthink?<br />More Fundamentals?<br />More Examples?<br />Pleaseletmeknow!<br />voelter@acm.org<br />
  64. THE END.<br />THE END.<br />

×