Agile Architecture Tech And Patterns

2,696 views
2,610 views

Published on

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

No Downloads
Views
Total views
2,696
On SlideShare
0
From Embeds
0
Number of Embeds
1,011
Actions
Shares
0
Downloads
192
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • Agile Architecture Tech And Patterns

    1. 1. Kirk Knoernschild Analyst, SDLC and Containers, Agile Architecture - Patterns & Technology Languages, & Frameworks Burton Group www.burtongroup.com kknoernschild@burtongroup.com Blog: http://apsblog.burtongroup.com Blog: http://techdistrict.kirkk.com Twitter: pragkirk
    2. 2. Agile Architecture 2 The Law of Two Feet If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet. Go to some other place where you may learn and contribute. Image Source: http://www.flickr.com/photos/jamesfarnham/32302798/
    3. 3. Agile Architecture 3 Defining Architecture Modularity The Patterns Patterns Applied
    4. 4. Agile Architecture 3 Defining Architecture Modularity The Patterns Patterns Applied
    5. 5. Agile Architecture 4 Defining Architecture What What What is arc is is hitect ure? archit the goal of archit ag ile ecture ecture ? ?
    6. 6. Defining Architecture 5 Preliminary Thoughts • Architects architect architecture • “Architecture is design, but not all design is architecture”.1 • We are often asked to design solutions to problems that require knowledge we currently do not possess. • Gall’s Law • A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. 2 • This session describes my approach to agile architecture. It is not all-inclusive, nor necessarily complete. Your feedback is valued and encouraged! 1. Booch made this statement. 2. John Gall. “How Systems Really Work and How They Fail.” P. 71
    7. 7. Defining Architecture 6 What is Architecture? • An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural elements and behavioral elements into progressively larger subsystems, and the architecture style that guides this organization -- these elements and their interfaces, their collaborations, and their composition. Source: Kruchten: The Rational Unified Process. Also cited in Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999
    8. 8. Defining Architecture 7 What is Architecture? • In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers...Architecture is about the important stuff. Whatever that is. Source: Fowler, Martin. IEEE Software, 2003. “Who Needs an Architecture.” A quote from Ralph Johnson on the XP mailing list.
    9. 9. Defining Architecture 8 What is Architecture? • The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. Source: ANSI/IEEE Std 1471-2000
    10. 10. Defining Architecture 9 What is Architecture? • A formal description of a system, or a detailed plan of the system at component level to guide its implementation • The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. Source: TOGAF - http://www.opengroup.org/architecture/togaf8-doc/arch/chap01.html
    11. 11. Defining Architecture 10 What is Architecture? • Architecture embodies the critical design decisions that typify a system. • Relates to cost of change, organizational structure, structure of code, capabilities of a system, etc. • The significance of decisions needs to be understood and assessed • A heavy-weight approach is likely to reduce understanding and our ability to assess Source: QCON London Presentation by James Coplien & Kevlin Henney title Agile Architecture Is not Fragile Architecture - http://www.infoq.com/presentations/Agile- Architecture-Is-Not-Fragile-Architecture-James-Coplien-Kevlin-Henney
    12. 12. Defining Architecture 11 The Goal of Architecture
    13. 13. Defining Architecture 11 The Goal of Architecture What if we were able to reduce the impact and cost of change?
    14. 14. Defining Architecture 11 The Goal of Architecture What if we were able to reduce the impact and cost of change? We n ee d t elimin o ate archit ectur e!
    15. 15. Defining Architecture 12 Architecture Paradox Increa sing e decre vo ases s lvability ur viva bility ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect”
    16. 16. Defining Architecture 12 Architecture Paradox We m Increa ust re sing e decre vo which cogniz e ases s lvability areas ur viva system of the bility deman increa d the se d co that w mplex ill bri ity greate ng r flex ibility! ... making everything easy to change makes the entire system very complex... - Ralph Johnson in “Who Needs an Architect”
    17. 17. Defining Architecture 13 I contend... • Architecture requires modularity • otherwise, how do we understand the impact of change • how do we identify areas of the system that demand flexibility • Agile architecture requires decision temporality • we cannot create solutions today for that which we will not know until tomorrow • otherwise we’ll create unnecessarily complex designs that do not address the impact of change
    18. 18. Agile Architecture 14 Modularity What Why i What is mo d s mo d ch ular neces ula us to d allenges fa ity? sar y c rity a ay in c of ag i o mp o n mo dul design e le arc ent ar sof in hitect tware g ure? ?
    19. 19. Modularity 15 Defining Module Hey, it’s a JAR file! - unit of reu - unit se of co m - unit po of dep sition - unit loyme of ma nt nagem ent
    20. 20. Modularity 15 Defining Module Hey, it’s a JAR file! - unit of reu - unit se of co m - unit po of dep sition - unit loyme of ma nt nagem ent A module system provides a runtime environment for modules
    21. 21. Modularity 16 Advantages of Modularity - reus e - re du ce co m - ease ple mainte xity - incr nance ease exten sibility
    22. 22. Modularity 17
    23. 23. Modularity 17 as change occurs
    24. 24. Modularity 17 as change occurs modules and their dependencies
    25. 25. Modularity 17 as change occurs isolate change modules and their dependencies
    26. 26. Modularity 17 as change occurs isolate change modules and their dependencies
    27. 27. Modularity 18 Architectural Joints Which ar system ea of the deman flexib ds mo ility? re
    28. 28. Modularity 18 Architectural Joints Which ar system ea of the deman flexib ds mo ility? re
    29. 29. Modularity 19 Module Design Few teams are designing software systems this way today! POLL: Question: Response: ----------------------------------------------------- - How many design class relationships? _____ - How many design package relationships? _____ - How many design module (JAR, Assembly) relationships? _____
    30. 30. Modularity 20 Platform Modularity Why a re design n’t we ing mo mo dul re ar sof tware ?
    31. 31. Modularity 20 Platform Modularity Why a re design n’t we Platforms discourage modularity! ing mo mo dul re ar sof tware ?
    32. 32. Modularity 21 Platform Modularity But w hat if platfo the rm enco u rage d mo dul arity?
    33. 33. Modularity 21 Platform Modularity But w This is the next generation application platform! hat if platfo the rm enco u rage d mo dul arity?
    34. 34. Modularity 22 Runtime Model - Dyn am - Mult ic deployme ipl nt - Enfo e versions rce depen dencie s
    35. 35. Modularity 23 Development Model Progra Design m ming Para d - The Mo del - The igm frame techn an d te works use d t iques ch that a nolog ies create o i den tify a llow u the ri nd create s to of mo ght se mo dul dules t softw ar are
    36. 36. Modularity 23 Development Model Progra Design m ming Para d - The Mo del - The igm frame techn an d te works use d t iques ch that a nolog ies create o i den tify a llow u the ri nd create s to of mo ght se mo dul dules t softw ar are The Design Paradigm - What’s the right granularity for a module? - What the right weight for a module?
    37. 37. Modularity 24 Modular Tension Maximizing reuse complicates use
    38. 38. Modularity 24 Modular Tension Maximizing reuse complicates use - SOL ID - Desi gn Pat - Mo d terns ularity Patter ns
    39. 39. Agile Architecture 25 The Patterns What ar mo dul e the arity patter ns?
    40. 40. The Patterns 26 Base Patterns • ManageRelationships – Design Module Relationships. • ModuleReuse – Emphasize reusability at the module level • CohesiveModules – Create cohesive modules. • ClassReuse - Classes not reused together belong in separate components.
    41. 41. The Patterns 27 Dependency Patterns • AcyclicRelationships - Module relationships must be acyclic. • LevelizeModules – Module relationships should be levelized • PhysicalLayers - Module relationships should not violate the conceptual layers. • ContainerIndependence - Consider your modules container dependencies. • IndependentDeployment - Modules should be independently deployable units. • CollocateExceptions - Exceptions should be close to the classes that throw them.
    42. 42. The Patterns 28 Usability Patterns • PublishedInterface - Make a modules published interface well known. • ExternalConfiguration – Modules should be externally configurable. • ModuleFacade – Create a facade serving as a coarse-grained entry point to the modules underlying implementation.
    43. 43. The Patterns 29 Extensibility Patterns • StableModules - Modules heavily depended upon should be stable. • AbstractModules - Depend upon the abstract elements of a module. • ImplementationFactory - Use factories to create a modules implementation classes. • SeparateAbstractions - Separate abstractions from the classes that realize them.
    44. 44. The Patterns 30 Utility Patterns • LevelizedBuild – Execute the build in accordance with module levelization. • TestComponent – For each module, create a test component that validates it’s behavior and illustrates usage.
    45. 45. Agile Architecture 31 Patterns Applied How c How d an I u o they mo dul se the acco m h arity mo dat elp patter archit e ns? ectura l shift s?
    46. 46. Patterns Applied 32 The System Design a system to handle payment and auditing of various types of bills. The system must integrate with 3rd party auditing software, and a legacy financials system that must be fed payment information for reconciliation.
    47. 47. Patterns Applied 33 Initial System Class Diagram Note t he bi- direct io n associ al ations !
    48. 48. Patterns Applied 34 Initial System Modules If I la yer conce ptu physic ally but no all t I real y, then am izing t a dvan he tages layeri of ng? W layer ? hy do I
    49. 49. Patterns Applied 35 Physical Layers • Module relationships should not violate the conceptual layers.
    50. 50. Patterns Applied 36 Abstract Modules • Depend upon the abstract elements of a module. - “Inje ct implem ” the entati Client. on int o - “Lo o ku implem p” the entati w ithin on Client.
    51. 51. Patterns Applied 37 Abstract Modules What if Bill be ab m le to u ust differ se ent au system diting s?
    52. 52. Patterns Applied 38 Abstract Modules Au ditF ac inject a de1 is e d int as an oB Au ditF ill type. aca de
    53. 53. Patterns Applied 39 Abstract Modules
    54. 54. Patterns Applied 40 Acyclic Relationships • Module relationships must be acyclic.
    55. 55. Patterns Applied 41 Recall - Abstract Modules Class Diagram Au ditF ac inject a de1 is e d int as an oB Au ditF ill type. aca de
    56. 56. Patterns Applied 42 Recall - Abstract Modules
    57. 57. Patterns Applied 43 Uni-Directional Associations
    58. 58. Patterns Applied 44 Acyclic Relationships
    59. 59. Patterns Applied 45 Separate Abstractions • Separate abstractions from the classes that realize them. How d o I integr ate w ith anoth er au diting syste m? W here does Audit Facad live? e2
    60. 60. Patterns Applied 46 Separate Abstractions Shoul d I p ut Audit Facad e2 in audit. jar?
    61. 61. Patterns Applied 47 Separate Abstractions
    62. 62. Patterns Applied 48 CollocateExceptions • Exceptions should be close to the classes that throw them. Audit Facad e throw s the Audit Excep tion.
    63. 63. Patterns Applied 49 Independent Deployment • Modules should be independently deployable units. How d o I re bill.ja use r with financ out ial.ja in a b r? Lik atch e applic ation?
    64. 64. Patterns Applied 50 Independent Deployment
    65. 65. Patterns Applied 51 Independent Deployment 1.) PayAction invokes Bill.pay() and passes BillPayAdapter as a BillPayer. 2.) Bill.pay() invokes BillPayer.generateDraft() 3.)BillPayAdapeter.generateDraft() invokes Payment.generateDraft() passing itself as a Payable. 4.) Payment.generateDraft() invokes Payable.getAmount()
    66. 66. Patterns Applied 52 Independent Deployment
    67. 67. Patterns Applied 53 Implementation Factory • Use factories to create a modules implementation classes.
    68. 68. Patterns Applied 54 Final Module Structure
    69. 69. Patterns Applied 55 Opportunities for Extension
    70. 70. Agile Architecture 56 Additional Resources • OSGi - http://www.osgi.org • JarAnalyzer - http://www.kirkk.com/main/Main/JarAnalyzer • Illustrates dependencies between JAR files • Google Code - http://code.google.com/p/jaranalyzer/
    71. 71. Agile Architecture 57 irk Knoernschild Presented By: K m kknoernschild @burtongroup.co m p ragkirk@kirkk.co m http://te chdistrict.kirkk.co

    ×