T14 Class 11/12/2009 2:45:00 PM "Agile Architecture: Patterns - - PDF document

▶
t14
SMART_READER_LITE
LIVE PREVIEW

T14 Class 11/12/2009 2:45:00 PM "Agile Architecture: Patterns - - PDF document

Apr 09, 2024 282 likes •1.02k views

T14 Class 11/12/2009 2:45:00 PM "Agile Architecture: Patterns and Technology" Presented by: Kirk Knoernschild Burton Group Presented at: Agile Development Practices Conference & EXPO 2009 November 9 13, 2009 Orlando, Florida 330

slide-1
SLIDE 1

T14

Class 11/12/2009 2:45:00 PM

"Agile Architecture: Patterns and Technology"

Presented by:

Kirk Knoernschild Burton Group

Presented at: Agile Development Practices Conference & EXPO 2009 November 9‐13, 2009 Orlando, Florida 330 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

slide-2
SLIDE 2

Kirk Knoernschild

A software developer currently working as an analyst for Burton Group, Kirk Knoernschild has more than fifteen years of software development experience during which he has filled most roles on the software development team. Kirk is an open source contributor, has authored Java Design: Objects, UML, and Process and numerous articles, and is a frequent conference speaker. He has trained and mentored thousands

  • f software professionals on topics including Java/J2EE, modeling, software architecture

and design, component-based development, service-oriented architecture, and software

  • process. Kirk enjoys hacking in a variety of languages.
slide-3
SLIDE 3

Agile Architecture

Kirk Knoernschild

Analyst, SDLC and Containers, Languages, & Frameworks Burton Group www.burtongroup.com kknoernschild@burtongroup.com Blog: http://apsblog.burtongroup.com Blog: http://techdistrict.kirkk.com Twitter: pragkirk Tuesday, September 1, 2009

slide-4
SLIDE 4

Agile Architecture

The Law of Two Feet

2

Image Source: http://www.flickr.com/photos/jamesfarnham/32302798/

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.

Tuesday, September 1, 2009

slide-5
SLIDE 5

Agile Architecture

3

Defining Architecture Modularity The Patterns Patterns Applied

Tuesday, September 1, 2009

slide-6
SLIDE 6

Agile Architecture

3

Defining Architecture Modularity The Patterns Patterns Applied

Tuesday, September 1, 2009

slide-7
SLIDE 7

Agile Architecture

4

Defining Architecture

What is architecture? What is the goal of architecture? What is agile architecture?

Tuesday, September 1, 2009

slide-8
SLIDE 8

Defining Architecture

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.

5

  • 1. Booch made this statement.
  • 2. John Gall. “How Systems Really Work and How They Fail.” P. 71

Your feedback is valued and encouraged!

Tuesday, September 1, 2009

slide-9
SLIDE 9

Defining Architecture

What is Architecture?

  • An architecture is the set of significant decisions about the
  • rganization 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

  • rganization -- these elements and their interfaces, their

collaborations, and their composition.

6

Source: Kruchten: The Rational Unified Process. Also cited in Booch, Rumbaugh, and Jacobson: The Unified Modeling Language User Guide, Addison-Wesley, 1999

Tuesday, September 1, 2009

slide-10
SLIDE 10

Defining Architecture

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.

7

Source: Fowler, Martin. IEEE Software, 2003. “Who Needs an Architecture.” A quote from Ralph Johnson on the XP mailing list.

Tuesday, September 1, 2009

slide-11
SLIDE 11

Defining Architecture

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.

8

Source: ANSI/IEEE Std 1471-2000

Tuesday, September 1, 2009

slide-12
SLIDE 12

Defining Architecture

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

  • ver time.

9

Source: TOGAF - http://www.opengroup.org/architecture/togaf8-doc/arch/chap01.html

Tuesday, September 1, 2009

slide-13
SLIDE 13

Defining Architecture

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

10

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

Tuesday, September 1, 2009

slide-14
SLIDE 14

Defining Architecture

The Goal of Architecture

11

Tuesday, September 1, 2009

slide-15
SLIDE 15

Defining Architecture

The Goal of Architecture

11

What if we were able to reduce the impact and cost of change?

Tuesday, September 1, 2009

slide-16
SLIDE 16

Defining Architecture

The Goal of Architecture

11

What if we were able to reduce the impact and cost of change?

We need to eliminate architecture!

Tuesday, September 1, 2009

slide-17
SLIDE 17

Defining Architecture

Architecture Paradox

12

Increasing evolvability decreases survivability

... making everything easy to change makes the entire system very complex...

  • Ralph Johnson in “Who Needs an Architect”

Tuesday, September 1, 2009

slide-18
SLIDE 18

Defining Architecture

Architecture Paradox

12

Increasing evolvability decreases survivability We must recognize which areas of the system demand the increased complexity that will bring greater flexibility!

... making everything easy to change makes the entire system very complex...

  • Ralph Johnson in “Who Needs an Architect”

Tuesday, September 1, 2009

slide-19
SLIDE 19

Defining Architecture

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

13

Tuesday, September 1, 2009

slide-20
SLIDE 20

Agile Architecture

14

Modularity

What is modularity? Why is modularity a necessary component

  • f agile architecture?

What challenges face us today in designing modular software?

Tuesday, September 1, 2009

slide-21
SLIDE 21

Modularity

Defining Module

15

  • unit of reuse
  • unit of composition
  • unit of deployment
  • unit of management

Hey, it’ s a JAR file!

Tuesday, September 1, 2009

slide-22
SLIDE 22

Modularity

Defining Module

15

  • unit of reuse
  • unit of composition
  • unit of deployment
  • unit of management

A module system provides a runtime environment for modules Hey, it’ s a JAR file!

Tuesday, September 1, 2009

slide-23
SLIDE 23

Modularity

Advantages of Modularity

16

  • reuse
  • reduce complexity
  • ease maintenance
  • increase

extensibility

Tuesday, September 1, 2009

slide-24
SLIDE 24

Modularity

17

Tuesday, September 1, 2009

slide-25
SLIDE 25

Modularity

17

as change occurs

Tuesday, September 1, 2009

slide-26
SLIDE 26

Modularity

17

as change occurs modules and their dependencies

Tuesday, September 1, 2009

slide-27
SLIDE 27

Modularity

17

as change occurs modules and their dependencies isolate change

Tuesday, September 1, 2009

slide-28
SLIDE 28

Modularity

17

as change occurs modules and their dependencies isolate change

Tuesday, September 1, 2009

slide-29
SLIDE 29

Modularity

Architectural Joints

18

Which area of the system demands more flexibility?

Tuesday, September 1, 2009

slide-30
SLIDE 30

Modularity

Architectural Joints

18

Which area of the system demands more flexibility?

Tuesday, September 1, 2009

slide-31
SLIDE 31

Modularity

19

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? _____

Module Design

Tuesday, September 1, 2009

slide-32
SLIDE 32

Modularity

20

Why aren’ t we designing more modular software?

Platform Modularity

Tuesday, September 1, 2009

slide-33
SLIDE 33

Modularity

20

Why aren’ t we designing more modular software?

Platforms discourage modularity! Platform Modularity

Tuesday, September 1, 2009

slide-34
SLIDE 34

Modularity

21

But what if the platform encouraged modularity?

Platform Modularity

Tuesday, September 1, 2009

slide-35
SLIDE 35

Modularity

21

But what if the platform encouraged modularity?

This is the next generation application platform! Platform Modularity

Tuesday, September 1, 2009

slide-36
SLIDE 36

Modularity

Runtime Model

22

  • Dynamic deployment
  • Multiple versions
  • Enforce

dependencies

Tuesday, September 1, 2009

slide-37
SLIDE 37

Modularity

Development Model

23

Programming Model

  • The frameworks

and technologies that allow us to create modular software Design Paradigm

  • The techniques

used to identify and create the right set

  • f modules

Tuesday, September 1, 2009

slide-38
SLIDE 38

Modularity

Development Model

23

Programming Model

  • The frameworks

and technologies that allow us to create modular software Design Paradigm

  • The techniques

used to identify and create the right set

  • f modules

The Design Paradigm

  • What’s the right granularity for a module?
  • What the right weight for a module?

Tuesday, September 1, 2009

slide-39
SLIDE 39

Modularity

Modular Tension

24

Maximizing reuse complicates use

Tuesday, September 1, 2009

slide-40
SLIDE 40

Modularity

Modular Tension

24

Maximizing reuse complicates use

  • SOLID
  • Design Patterns
  • Modularity

Patterns

Tuesday, September 1, 2009

slide-41
SLIDE 41

Agile Architecture

25

The Patterns

What are the modularity patterns?

Tuesday, September 1, 2009

slide-42
SLIDE 42

The Patterns

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.

26

Tuesday, September 1, 2009

slide-43
SLIDE 43

The Patterns

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.

27

Tuesday, September 1, 2009

slide-44
SLIDE 44

The Patterns

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.

28

Tuesday, September 1, 2009

slide-45
SLIDE 45

The Patterns

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.

29

Tuesday, September 1, 2009

slide-46
SLIDE 46

The Patterns

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.

30

Tuesday, September 1, 2009

slide-47
SLIDE 47

Agile Architecture

31

Patterns Applied

How can I use the modularity patterns? How do they help accommodate architectural shifts?

Tuesday, September 1, 2009

slide-48
SLIDE 48

Patterns Applied

32

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.

The System

Tuesday, September 1, 2009

slide-49
SLIDE 49

Patterns Applied

33

Initial System Class Diagram

Note the bi- directional associations!

Tuesday, September 1, 2009

slide-50
SLIDE 50

Patterns Applied

34

Initial System Modules

If I layer conceptually but not physically, then am I realizing the advantages of layering? Why do I layer?

Tuesday, September 1, 2009

slide-51
SLIDE 51

Patterns Applied

Physical Layers

  • Module relationships should not violate the conceptual layers.

35

Tuesday, September 1, 2009

slide-52
SLIDE 52

Patterns Applied

Abstract Modules

  • Depend upon the abstract elements of a module.

36

  • “Inject” the

implementation into Client.

  • “Lookup” the

implementation within Client.

Tuesday, September 1, 2009

slide-53
SLIDE 53

Patterns Applied

Abstract Modules

37

What if Bill must be able to use different auditing systems?

Tuesday, September 1, 2009

slide-54
SLIDE 54

Patterns Applied

Abstract Modules

38

AuditFacade1 is injected into Bill as an AuditFacade type.

Tuesday, September 1, 2009

slide-55
SLIDE 55

Patterns Applied

Abstract Modules

39

Tuesday, September 1, 2009

slide-56
SLIDE 56

Patterns Applied

Acyclic Relationships

  • Module relationships must be acyclic.

40

Tuesday, September 1, 2009

slide-57
SLIDE 57

Patterns Applied

Recall - Abstract Modules Class Diagram

41

AuditFacade1 is injected into Bill as an AuditFacade type.

Tuesday, September 1, 2009

slide-58
SLIDE 58

Patterns Applied

Recall - Abstract Modules

42

Tuesday, September 1, 2009

slide-59
SLIDE 59

Patterns Applied

Uni-Directional Associations

43

Tuesday, September 1, 2009

slide-60
SLIDE 60

Patterns Applied

Acyclic Relationships

44

Tuesday, September 1, 2009

slide-61
SLIDE 61

Patterns Applied

Separate Abstractions

  • Separate abstractions from the classes that realize them.

45

How do I integrate with another auditing system? Where does AuditFacade2 live?

Tuesday, September 1, 2009

slide-62
SLIDE 62

Patterns Applied

Separate Abstractions

46

Should I put AuditFacade2 in audit.jar?

Tuesday, September 1, 2009

slide-63
SLIDE 63

Patterns Applied

Separate Abstractions

47

Tuesday, September 1, 2009

slide-64
SLIDE 64

Patterns Applied

CollocateExceptions

  • Exceptions should be close to the classes that throw them.

48

AuditFacade throws the AuditException.

Tuesday, September 1, 2009

slide-65
SLIDE 65

Patterns Applied

Independent Deployment

  • Modules should be independently deployable units.

49

How do I reuse bill.jar without financial.jar? Like in a batch application?

Tuesday, September 1, 2009

slide-66
SLIDE 66

Patterns Applied

Independent Deployment

50

Tuesday, September 1, 2009

slide-67
SLIDE 67

Patterns Applied

Independent Deployment

51

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()

Tuesday, September 1, 2009

slide-68
SLIDE 68

Patterns Applied

Independent Deployment

52

Tuesday, September 1, 2009

slide-69
SLIDE 69

Patterns Applied

Implementation Factory

  • Use factories to create a modules implementation classes.

53

Tuesday, September 1, 2009

slide-70
SLIDE 70

Patterns Applied

Final Module Structure

54

Tuesday, September 1, 2009

slide-71
SLIDE 71

Patterns Applied

Opportunities for Extension

55

Tuesday, September 1, 2009

slide-72
SLIDE 72

Agile Architecture

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/

56

Tuesday, September 1, 2009