Best Practices in Software Architecture - PowerPoint PPT Presentation

Loading...

PPT – Best Practices in Software Architecture PowerPoint presentation | free to view - id: 1b10d5-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Best Practices in Software Architecture

Description:

Developed by geographically- temporally-distributed teams ... Baroque. Engineering/Rational/National/Romantic. Art Noveau. Modernism. 29. 2008 Grady Booch ... – PowerPoint PPT presentation

Number of Views:119
Avg rating:3.0/5.0
Slides: 108
Provided by: Grady1
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Best Practices in Software Architecture


1
Best Practices in Software Architecture
  • Grady Booch

2
The Current State
  • The typical software-intensive system is
  • Continuously evolving
  • Connected, distributed, concurrent
  • Multilingual multiplatform
  • Secure autonomic
  • Developed by geographically- temporally-distribute
    d teams
  • Most systems are actually systems of systems
  • Services other messaging mechanisms dominate
  • Such systems encompass both hardware software

3
Growth Of Storage
  • The production of data is growing
  • Google processes 20 petabytes/day1
  • The Internet handles over 627 petabytes/day2
  • Storage densities are increasing
  • 200 gigabytes/inch2 are common today
  • Racetrack memory could increase storage density
    by two orders of magnitude (20,000
    gigabytes/inch2)3

Opportunity
1http//www.niallkennedy.com/blog/2008/01/google-m
apreduce-stats.html 2http//en.wikipedia.org/wiki/
Petabyte 3http//www.almaden.ibm.com/spinaps/resea
rch/sd/?racetrack
4
Growth Of Computational Power
  • Computational power is abundant
  • A single BladeCenter can reach 7 teraflops
  • IBM Road Runner has reached one petaflop
  • Hardware costs are around 20 cents/gigaflop
    operating costs are approximately 3
    watts/gigaflop1
  • The frequency scaling wars are ending
  • At 10 atoms/transistor, quantum effects power
    dissipation become critical issues issues
  • Multicore processors are becoming the norm

Opportunity
1http//en.wikipedia.org/wiki/FLOPS
5
Growth Of Connectivity
  • Bandwidth is increasing
  • Copper may reach 10 gigabytes/second
  • Wireless networks are becoming pervasive
  • Out of 3.7 billion IPv4 addresses1
  • China 19.246 million
  • US 13.610 million
  • Germany 5.414 million
  • Italy 3.881 million
  • Indonesia 3.465 million
  • Taiwan 3.455 million

Opportunity
1http//www.bgpexpert.com/addressespercountry.ph
p
6
Future Software-Intensive Systems
  • Future systems will be just like contemporary
    ones except they will be
  • More massive
  • More pervasive
  • More transparent
  • More critical
  • Domain-specific platforms are growing in
    dominance

7
Agenda
  • Architecture defined and defended
  • Architecture best practices
  • Software archeology
  • Process and governance
  • Organizational patterns
  • Handbook and preservation

8
Architecture defined and defended
9
Fundamentals
  • All architecture is design not all design is
    architecture. A systems architecture is defined
    by its significant design decisions (where
    significant is measured by the cost of change).
  • Most architectures are accidental some are
    intentional.
  • Every software-intensive system has an
    architecture, forged from the hundreds of
    thousands of small decisions made every day.
  • The code is the truth, but not the whole truth
    most architectural information is preserved in
    tribal memory.

10
Air Traffic Control
http//www.booch.com/architecture/architecture.jsp
?partGallery
11
ATM
http//www.booch.com/architecture/architecture.jsp
?partGallery
12
Battlefield Management
http//www.booch.com/architecture/architecture.jsp
?partGallery
13
Cargo Routing
http//www.booch.com/architecture/architecture.jsp
?partGallery
14
Computational Chemistry
http//www.booch.com/architecture/architecture.jsp
?partGallery
15
Enterprise
http//www.booch.com/architecture/architecture.jsp
?partGallery
16
Games
http//www.booch.com/architecture/architecture.jsp
?partGallery
17
Games
http//www.booch.com/architecture/architecture.jsp
?partGallery
18
Google
19
Linux
http//www.booch.com/architecture/architecture.jsp
?partGallery
20
MetLife
http//www.booch.com/architecture/architecture.jsp
?partGallery
21
Mobile Phone
http//www.booch.com/architecture/architecture.jsp
?partGallery
22
Mozilla
http//www.booch.com/architecture/architecture.jsp
?partGallery
23
Pathfinder
http//www.booch.com/architecture/architecture.jsp
?partGallery
24
Router
http//www.booch.com/architecture/architecture.jsp
?partGallery
25
Speech Recognition
http//www.booch.com/architecture/architecture.jsp
?partGallery
26
Washing Machine
http//www.booch.com/architecture/architecture.jsp
?partGallery
27
Web Server
http//www.booch.com/architecture/architecture.jsp
?partGallery
28
From vision to execution
http//www.gehrytechnologies.com/
29
Movements on civil architecture
  • Egyptian/Babylonian, Assyrian, Persian
  • Classical Indian
  • Dynastic China
  • Grecian/Roman
  • Early Christian/Byzantine
  • Islamic
  • Romanesque
  • Gothic
  • Renaissance
  • Palladian
  • Neoclassical
  • Picturesque
  • Mannerism
  • Baroque
  • Engineering/Rational/National/Romantic
  • Art Noveau
  • Modernism

Progress - Imitation of previous efforts -
Learning from failure - Integration of other
forces - Experimentation
Architects - Imhotep - Vitruvius -
Michelangelo - Palladio - Wright - Wren -
LeCorbusier - Geary - Libeskind
Cole, The Grammar of Architecture
30
Movements in web-centric architectures
  • Simple documents
  • Colorful clients
  • Simple scripting
  • Rise of middleware
  • Rise of simple frameworks
  • Emergence of dynamic frameworks
  • Semantic web

31
Forces in civil architecture
Kinds of loads - Dead loads - Live loads -
Dynamic loads
Avoiding failure - Safety factors -
Redundancy - Equilibrium
Any time you depart from established practice,
make ten times the effort, ten times the
investigation. Especially on a very large
project. - LeMessuier
32
Forces in software
33
Patterns in physical systems
  • Calloway and Cromley's The Elements of Style
  • Alexander's The Nature of Order
  • The Phaidon Atlas of Contemporary World
    Architecture
  • Perry's Chemical Engineers' Handbook
  • Sclater and Chironis' Mechanism and Mechanical
    Devices Sourcebook
  • Christiansen's Electrical Engineers' Handbook
  • ICRF Handbook of Genome Analysis

34
Software patterns
  • Buschman, Pattern-Oriented Software Architecture
  • Dyson, Architecting Enterprise Solutions
  • Fowler, Patterns of Enterprise Application
    Architecture
  • Gamma et al, Design Patterns
  • Hohpe et al, Enterprise Integration Patterns
  • Kircher, Pattern-Oriented Software Architecture
  • Schmidt, Pattern-Oriented Software Architecture
  • Shaw/Garland Software Architecture
  • Towbridge et al, Integration Patterns

35
Physical systems
  • Mature physical systems have stable architectures
  • Aircraft, cars, and ships
  • Bridges and buildings
  • Such architectures have grown over long periods
    of time
  • Trial-and-error
  • Reuse and refinement of proven solutions
  • Quantitative evaluation with analytical methods
  • Mature domains are dominated by engineering
    efforts
  • Analytical engineering methods
  • New materials and manufacturing processes

36
Architecting software is different
  • No equivalent laws of physics
  • Transparency
  • Complexity
  • Combinatorial explosion of state space
  • Non-continuous behavior
  • Systemic issues
  • Requirement and technology churn
  • Low replication and distribution costs

37
The limits of software
  • The laws of physics
  • The laws of software
  • The challenge of algorithms
  • The difficulty of distribution
  • The problems of design
  • The importance of organization
  • The impact of economics
  • The influence of politics
  • The limits of human imagination

38
The entire historyof software engineering is one
of rising levels of abstraction
Assembly ? Fortran/COBOL ? Simula ? C ?
Java Naked HW ? BIOS ? OS ? Middleware ?
Domain-specific Waterfall ? Spiral ? Iterative ?
Agile Procedural ? Object Oriented ? Service
Oriented Early tools ? CLE ? IDE ? XDE ?
CDE Individual ? Workgroup ? Organization
Languages Platforms Processes Architecture Too
ls Enablement
39
Architecture defined
  • IEEE 1471-2000
  • Software architecture is 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
  • Software architecture encompasses the set of
    significant decisions about the organization of a
    software system
  • Selection of the structural elements and their
    interfaces by which a system is composed
  • Behavior as specified in collaborations among
    those elements
  • Composition of these structural and behavioral
    elements into larger subsystems
  • Architectural style that guides this organization

Source Booch, Kruchten, Reitman, Bittner, and
Shaw
40
Why Architecture?
  • In hyper-productive projects
  • Process centers around growing an executable
    architecture
  • Well-structured systems are full of patterns
  • Why architecture?
  • Risk-confrontive
  • Simplicity
  • Resilience

41
Architecture best practices
42
Fundamentals
  • Crisp abstractions
  • Clear separation of concerns
  • Balanced distribution of responsibilities
  • Simplicity

43
What we know we know
  • Every software-intensive system has an
    architecture
  • We generally understand what software
    architecture is and what it is not
  • Different stakeholders have different concerns
    and therefore different viewpoints
  • All well-structured software-intensive systems
    are full of patterns

44
Definitions
  • Architecture
  • The fundamental organization of a system,
    embodied in its components, their relationships
    to each other, and the principles governing its
    design and evolution (IEEE Std 1471-2000, 2000,
    p. 3).
  • Stakeholder
  • An individual, team, or organization (or classes
    thereof) with interests in, or concerns relative
    to, a system (IEEE Std 1741-2000, 2000, p. 3).
  • Concern
  • Those interests which pertain to the system's
    development, its operation or any other aspects
    that are critical or otherwise important to one
    or more stakeholders. Concerns include system
    considerations such as performance, reliability,
    security, distribution, and evolvability (IEEE
    Std 1471-2000, 2000, p. 4).
  • View
  • A representation of a whole system from the
    perspective of a related set of concerns (IEEE
    Std 1471-2000, 2000, p. 3).

45
Architectural frameworks
  • AGATE
  • DoD Architecture Framework
  • Federal Enterprise Architecture
  • MoD Architecture Framework
  • Reference Model of Open Distributed Computing
  • Open Group Architecture Framework
  • Zachman Framework

46
Representing software architecture
Logical View
Implementation View
Programmers Configuration management
End-user
Functionality
Use Case View
Process View
Deployment View
System engineering
System topology Communication Provisioning
Conceptual
Physical
Kruchten, The 41 Model View
47
Architectural views
  • Use case view
  • The view of a system's architecture that
    encompasses the use cases that described the
    behavior of the system as seen by its end users
    and other external stakeholders.
  • Logical view
  • The physical place where a system is developed,
    used, or deployed.
  • Process view
  • The view of a system's architecture that
    encompasses the threads and processes that form
    the system's concurrency and synchronization
    mechanisms a process view addresses the
    performance, scalability, and throughput of the
    system.
  • Implementation view
  • The view of a system's architecture that
    encompasses the components used to assemble and
    release the physical system an implementation
    view addresses the configuration management of
    the system's releases, made up of somewhat
    independent components that can be assembled in
    various well-structured ways to produce a running
    system.
  • Deployment view
  • The view of a system's architecture that
    encompassesthe nodes the form the system's
    hardware topology on which the system executes a
    deployment view addresses the distribution,
    delivery, and installation of the parts that make
    up the physical system.

48
Architecture metamodel
49
Architecture metamodel
50
Architecture metamodel
51
What We Are Fairly Certain We Know
  • We are starting to develop a profession of
    software architecture
  • We are starting to see the emergence of
    domain-specific software architectures

52
What We Know We Dont Know
  • We still dont have formal architectural
    representations that scale
  • We dont yet have a good understanding of the
    architectural patterns that are found among
    domains.

53
Misconceptions About Architecture
  • Architecture is just paper
  • Architecture and design are the same things
  • Architecture and infrastructure are the same
    things
  • ltmy favorite technologygt is the architecture
  • A good architecture is the work of a single
    architect
  • Architecture is simply structure
  • Architecture can be represented in a single
    blueprint
  • System architecture precedes software
    architecture
  • Architecture cannot be measured or validated
  • Architecture is a science
  • Architecture is an art

Kruchten
54
Sources of Architecture
Method
Method
Theft
Intuition
Theft
Intuition
Classical System
Unprecedented System
Kruchten
55
Complex systems
  • From Complexity by Mitchell Waldrop
  • A great many independent agents are interacting
    with each other in a great many ways.
  • The very richness of these interactions allows
    the system as a whole to undergo spontaneous
    self-organization.
  • These complex, self-organizing systems are
    adaptive.
  • All these complex systems have somehow acquired
    the ability to bring order and chaos into a
    special kind of balance.

56
Complex systems
  • From Sciences of the Artificialby Herbert Simon
  • Hierarchic systems are usually composed of only
    a few different kinds of subsystems in various
    combinations and arrangements.
  • Hierarch systems are often nearly
    decomposable. Hence only aggregative properties
    of their parts enter into the description of the
    interactions of those parts.
  • By appropriate recoding the redundancy that is
    present but unobvious in the structure of a
    complex system can often be made patent.

57
Measuring architectural complexity
  • SLOC
  • For each view
  • Number of things
  • Number of patterns
  • Rate of change over time

58
Economics of architecture first
  • Architecture is an important artifact of
    governance
  • Focusing on a systems architecture provides a
    means of intentional simplification
  • Devising a sound software-intensive architecture
    is essential to building systems that are
    resilient to change
  • Well-architected systems make possible the
    creation of software product lines
  • Intentional architectures serve to preserve
    critical intellectual property and reduce the
    quantity of tribal memory

59
Process and governance
60
Fundamentals
  • Development takes place at two levels
    architecture and implementation.
  • Both are ongoing, and they interact with each
    other strongly. New implementations suggest
    architectural changes. Architectural changes
    usually require radical changes to the
    implementation.

Coplien, Organizational Patterns of Agile
Development, p. 332
61
Process
  • Grow a systems architecture through the
    incremental and iterative release of testable
    executables
  • Architecture as an artifact of governance
  • Stepwise refinement
  • Focus on code

62
Governance
  • Attack risk
  • Measure progress
  • Encourage innovation
  • Enable simplification

63
Software archeology
64
Software archeology
  • The recovery of essential details about an
    existing system sufficient to reason about, fix,
    adapt, modify, harvest, and use that system
    itself or its parts

65
Why we dig
  • To reason about
  • CAATS
  • To fix
  • Y2K
  • To adapt
  • Homeland Security
  • To modify
  • JPL Mars Rovers
  • To harvest
  • Patriot Missile System
  • To use
  • AWACS Mid-term modernization

66
Process of archeology
  • Study of the source code
  • Reverse engineering
  • Probing and other instrumentation
  • Review of existing documents
  • Interviews with tribal leaders

67
Process of archeology
  • Most design information lives in tribal memory
  • Typically there exists very high level
    architectural views and very low level design
    views, but little in between
  • Reconstructing deployment and implementation
    views is easy
  • Reconstructing the use case view is possible
  • Reconstructing the logical and process views is
    hard
  • Harvesting patterns is harder still

68
Eclipse
  • www.eclipse.org
  • Eclipse was started about 2 yrs go - when IBM
    made a 40M contribution to the main code base
    but is now an independent entity
  • The principal architects are John Wiegand, Dave
    Thomson, John Duimovich all part of the OTI team
    which jump-started Eclipse.

69
Eclipse artifacts
  • Eclipse Platform Technical Overview
  • How to use the Eclipse API
  • Eclipse Overview
  • More detailed information exists for each of the
    subprojects.

70
Eclipse architecture
71
Eclipse use case view
  • Check In/Out Resource
  • Close Perspective
  • Close Window
  • Display Help
  • Invoke New Tool
  • Open Perspective
  • Open Window
  • Refresh Workspace
  • Shutdown Workbench
  • Startup Workbench

72
Eclipse implementation view
73
Eclipse logical view
  • Plugin Development Environment (PDE)
  • Workbench
  • Team
  • Debug
  • Ant
  • Help
  • Java Development Tools (JDT)

74
SWT
75
JDT
76
9 Things To Do With Old Software
  • Abandon it
  • Give it away
  • Ignore it
  • Put it on life support
  • Rewrite it
  • Harvest from it
  • Wrap it up
  • Transform it
  • Preserve it

77
Organizational patterns
78
Patterns
  • Architect patterns
  • Organizational patterns
  • Architecture patterns
  • Not included in this study
  • Architecture patterns are design patterns writ
    large

79
Architect patterns
80
Coplien, Organizational Patterns of Agile
Development
81
Coplien, Organizational Patterns of Agile
Development
82
Coplien, Organizational Patterns of Agile
Development
83
Developer controls process
  • Make the developer the focal point of process
    information.

Coplien, Organizational Patterns of Agile
Development, p. 71
84
Architect controls product
  • Even though a product is designed by many
    individuals, a project must strive to give the
    product elegance and cohesiveness. Create an
    architect role as an embodiment of the principles
    that define an architectural style for the
    project and of the broad domain expertise that
    legitimizes such a style

Coplien, Organizational Patterns of Agile
Development, p. 239
85
Architect also implements
  • Going forward, the project needs the necessary
    architectural breadth to cover its markets and to
    ensure smooth evolution, but it cant be
    blindsided by pragmatic engineering and
    implementation concerns. Beyond advising and
    communicating with Developers, Architects should
    also participate in implementation.

Coplien, Organizational Patterns of Agile
Development, pp. 254-255
86
Architecture team
  • You need to create an architecture that is simple
    and cohesive, but that also accommodates a
    variety of constituencies. Create a small team of
    resonating minds to define the initial
    architecture in such a way that the team covers
    the expected partitioning of the system.

Coplien, Organizational Patterns of Agile
Development, pp. 241-242
87
Lock em up together
  • A team of diverse people must come up with a
    single, coherent architecture. Gather domain
    experts together in the same room to work out the
    architecture (or other strategic issues).

Coplien, Organizational Patterns of Agile
Development, p. 243
88
Engage customers
  • Closely couple the Customer role with the
    Developer and Architect roles, not just with QA
    or marketing roles. In short, developers and
    architects must talk freely and often with
    customers. When possible, engage customers in
    their own environment rather than bringing them
    into your environment.

Coplien, Organizational Patterns of Agile
Development, p. 113
89
Stand up meeting
  • Hold short daily meetings with the entire team to
    exchange critical information, update status,
    and/or make assignments. The meetings should last
    no more than 15 minutes and generally should
    happen first thing in the morning. The focus of
    the meetings is on the technical progress in the
    architecture and in the work plan.

Coplien, Organizational Patterns of Agile
Development, p. 248
90
Named stable bases
  • It is important to integrate software frequently
    enough so that the base doesnt become stale, but
    not so frequently that you damage a shared
    understanding of what functionality is sound and
    trusted in an evolving software base. Stabilize
    systems interfaces the architecture about
    once a week. Give the stable system a name of
    some kind by which developers can identify their
    shared understanding of that versions
    functionality.

Coplien, Organizational Patterns of Agile
Development, p. 42
91
Decouple stages
  • Development stages should be independent to
    reduce coupling and to promote the autonomy of
    teams and developers. For known and mature
    domains, serialize the steps.

Coplien, Organizational Patterns of Agile
Development, p. 217
92
Conways law
  • Make sure the organization is compatible with the
    product architecture.

Coplien, Organizational Patterns of Agile
Development, p. 192
93
Organization follows location
  • The architectural partitioning should reflect the
    geographic partitioning, and vice versa.

Coplien, Organizational Patterns of Agile
Development, p. 195
94
Subsystem by skill
  • Birds of a feather flock together. Separate
    subsystems by staff skills and skill requirements.

Coplien, Organizational Patterns of Agile
Development, p. 153
95
Feature assignment
  • For every nontrivial project, it is impossible to
    partition the work cleanly. Assign features to
    people for development. Feature development has a
    finite duration and is, therefore, an assignment,
    not a role.

Coplien, Organizational Patterns of Agile
Development, p. 265
96
Organizational patterns
  • Big dripping hairball
  • Senior designer
  • Chief architect
  • Architecture team
  • Architecture control board

97
Big dripping hairball
  • Architecture is entirely accidental
  • Appropriate for small systems with short
    half-life
  • Appropriate to new systems requiring intense
    innovation
  • In such cases, experience is often/should be
    harvested from the initial system and then
    applied to a more structured process (with the
    original system thrown away)

98
Senior designer
  • Architecture is incrementally more intentional,
    drawn from the experience of the senior designer
  • Appropriate for small to modest-sized systems
    with modest half-life
  • Appropriate to new systems requiring modest
    innovation

99
Chief architect
  • The architecture is incrementally more
    intentional, because the risk is much higher
  • Appropriate for modest to large systems with
    modest to long half-life
  • Appropriate to brownfield systems requiring
    transformation

100
Architecture team
  • The architecture is quite intentional
  • Appropriate to large, complex software-intensive
    systems with high risk
  • Appropriate to systems with many technical,
    contextual, business, and economic dimensions.

101
Architecture control board
  • Architecture is fully intentional
  • Appropriate to very large systems-of-systems with
    deep economic weight
  • Appropriate to systems formed of many systems,
    some new, many old, and all largely in flux

102
Handbook and preservation
103
Handbook of Software Architecture
  • No architectural reference exists for
    software-intensive systems
  • Goals of the handbook
  • Codify the architecture of a large collection of
    interesting software-intensive systems
  • Study these architectural patterns in the context
    of the engineering forces that shaped them
  • Satisfy my curiosity

http//www.booch.com/architecture
104
  • Entertainment and Sports
  • Disney Hall of the Presidents
  • Hong Kong Jockey Club
  • NBC control room
  • Olympics
  • Spiderman
  • Veri-Lite
  • Financial
  • Fedline bond system
  • Great Plains
  • NYSE
  • Visa
  • Wells Fargo
  • Games
  • Deep Blue
  • Doom III
  • StarCraft
  • The Sims
  • Content Authoring
  • Avid
  • Massive
  • Microsoft Word
  • Photoshop
  • Renderman
  • Wall Street Journal
  • Yamaha
  • Development 
  • Eclipse
  • emacs
  • JIT
  • Devices  
  • Bernini Artista
  • CocaCola
  • Foveon camera
  • General Electric
  • Hamilton Automation
  • Otis
  • Artificial Intelligence
  • Asimo
  • Avida
  • Blondie24
  • CYC
  • Swarm
  • Trilogy
  • Commercial and Non-Profit  
  • Amazon
  • eBay
  • Home Depot
  • LDS
  • Library of Congress
  • Sabre
  • Starwood
  • Ticketmaster
  • Communications
  • 5ESS
  • 911

105
  • Scientific
  • ABI Prism
  • Earth Weather Simula
  • Jason
  • Mars Exploration Rover
  • Mathematica
  • Mona Loa observatory
  • National Data Buoy Center
  • National Ignition Facility
  • NavTech
  • Protein Data Bank
  • SETI_at_home
  • Transportation
  • BMW
  • British Rail
  • CAATS
  • Evans and Sutherland
  • Fedex
  • Ford
  • Military
  • AEGIS
  • AWACS
  • Bendix
  • Chyenne Mountain
  • F16
  • Force XXI
  • GPS
  • Pathfinder
  • Predator
  • Space Command
  • Operating Systems 
  • Linux
  • Palm OS
  • Wind River OS
  • Windows XP
  • Platforms 
  • .NET
  • J2EE
  • Industrial
  • Dow Chemical
  • NERTO
  • Toyota
  •  Legal
  • Identix
  • Lexis/Nexis
  • Supreme Court
  • Medical
  • Cogency
  • Medtronics
  • Philips
  • Siemens
  • Utilities
  • AOL Messenger
  • Babblefish
  • Google
  • Groove
  • sendmail

106
Preservation of Classic Software
  • No comprehensive and intentional activity has yet
    been undertaken to preserve software artifacts
  • There are a number of reasons to act now
  • Many of the authors of seminal systems are still
    alive
  • Many others may have the source code or design
    documents for these systems collecting dust in
    their offices or garages
  • Time is our enemy over time, these artifacts
    will become lost forever

http//www.computerhistory.org
107
Questions
About PowerShow.com