IBM Presentations: Blue Pearl DeLuxe template

Report
IBM Rational
The Complexity of
Programming Models
Grady Booch
IBM Fellow
© 2005 IBM Corporation
IBM Rational
How much software exists in the world?
 SLOC is a measure of labor (not of value)
– Old code never dies (you have to kill it)
– Some code is DOA
 Some assumptions
– 1 SLOC = 1 semicolon
– Number of software professionals worldwide
– %of software professionals who cut code
– SLOC/developer/year
– $100US/SLOC
2
© 2005 IBM Corporation
IBM Rational
Number of software professional worldwide
Number of IT professionals worldwide
16,000,000
3
2
y = -128.47x + 12800x - 59294x + 146623
14,000,000
12,000,000
10,000,000
8,000,000
Number of IT professionals worldwide
(assumptions)
Poly. (Number of IT professionals
worldwide (assumptions))
6,000,000
4,000,000
2,000,000
19
45
19
48
19
51
19
54
19
57
19
60
19
63
19
66
19
69
19
72
19
75
19
78
19
81
19
84
19
87
19
90
19
93
19
96
19
99
20
02
20
05
0
3
© 2005 IBM Corporation
IBM Rational
% of software professionals who cut code
% of IT professionals worldwide who cut code
80%
70%
60%
50%
of IT professionals worldwide who cut code %
)assumptions(
Poly. (% of IT professionals worldwide who cut
))code (assumptions
40%
30%
y = -0.0075x + 0.7575
20%
10%
4
2005
2003
2001
1999
1997
1995
1993
1991
1989
1987
1985
1983
1981
1979
1977
1975
1973
1971
1969
1967
1965
1963
1961
1959
1957
1955
1953
1951
1949
1947
1945
0%
© 2005 IBM Corporation
IBM Rational
SLOC/developer/year
New or modified source lines of code per year per developer
8,000
3
2
y = -0.0328x + 4.8392x - 67.596x + 1062.8
7,000
6,000
5,000
New or modified source lines of code per year
)per developer (assumptions
Poly. (New or modified source lines of code per
))year per developer (assumptions
4,000
3,000
2,000
1,000
5
2005
2003
2001
1999
1997
1995
1993
1991
1989
1987
1985
1983
1981
1979
1977
1975
1973
1971
1969
1967
1965
1963
1961
1959
1957
1955
1953
1951
1949
1947
1945
0
© 2005 IBM Corporation
IBM Rational
New or modified SLOC/year and cumulative
New or modified source lines of code per year per developer & cumulative
800,000,000,000
700,000,000,000
600,000,000,000
500,000,000,000
400,000,000,000
New or modified source lines of code per
year
Cumulative source lines of code
300,000,000,000
200,000,000,000
100,000,000,000
19
45
19
48
19
51
19
54
19
57
19
60
19
63
19
66
19
69
19
72
19
75
19
78
19
81
19
84
19
87
19
90
19
93
19
96
19
99
20
02
20
05
0
6
© 2005 IBM Corporation
IBM Rational
Dimensions of software complexity
Higher technical complexity
An average software project
- 5-10 people
- 3-9 month duration
- 3-5 external interfaces
- Some unknowns & risks
Lower
management
complexity
- Small scale
- Informal
- Single stakeholder
- “Products”
- Embedded, real-time, distributed, fault-tolerant
- Custom, unprecedented, architecture reengineering
- High performance
Telecom
Switch
Commercial
Embedded Compiler
Automotive
Software
CASE Tool
Small Scientific
Simulation
IS Application
Distributed Objects
(Order Entry)
Defense
Weapon System
National Air Traffic
Control System
Large-Scale
Organization/Entity
Simulation
Enterprise IS
(Family of IS
Applications)
Defense
MIS System
Higher
management
complexity
- Large scale
- Contractual
- Many stake holders
- “Projects”
IS Application
GUI/RDB
(Order Entry)
Business
Spreadsheet
Lower technical complexity
- Mostly 4GL, or component-based
- Application reengineering
- Interactive performance
Royce
7
© 2005 IBM Corporation
IBM Rational
Stakeholders and views
 A given system is many things to many different stakeholders
– End user
– Customer
– Sys admin
– Project manager
– System engineer
– Developer
– Architect
– Maintainer
– Tester
– Other systems
 Multiple realities, multiple views and multiple blueprints exist
8
© 2005 IBM Corporation
IBM Rational
Simplicity has different points of view
 User
– Simple metaphors and gestures
 End-user programmer
– Access to significant parts and flexible mechanisms for behavior
 Architect
– Common architectural patterns
 Developer
– Common design patterns and idioms
 Tester
– Access to significant parts
9
© 2005 IBM Corporation
IBM Rational
Simplicity has different points of view
 Business analyst
– Clear separation of rules
 Database analyst
– Purity of semantics
 Security officer
– Clear and perfectly executed policies
 Administrator
– Clear separation of components
10
© 2005 IBM Corporation
IBM Rational
In the presence of essential complexity,
establishing simplicity in one part of a system
requires trading off complexity in another
11
© 2005 IBM Corporation
IBM Rational
Creating the illusion of simplicity
12
© 2005 IBM Corporation
IBM Rational
Simplicity in languages
 Tradeoff between primitiveness and convenience
– Control structures
 Tradeoff between explicitness and abstraction
– Java garbage collection
 Tradeoff between performance of development and performance of
execution
– VisualBasic
– Smalltalk
 Tradeoff between packaging for design versus packaging for
development versus packaging for deployment
– Beans
– Services
– Aspects
13
© 2005 IBM Corporation
IBM Rational
A programming model specifies the
semantic universe within which the developer labors
and is defined by the languages, platforms, tools,
and best practices of that constellation
14
© 2005 IBM Corporation
IBM Rational
Web-centric programming model
 Languages
 Platforms
– HTML
– Linux
– Coding
– Eclipse
– CSS
– Apache
– Design patterns
– Dreamweaver
– MySQL
– Deployment
– Photoshop
– J2EE
– User interface
– ClearCase
– Accessibility
– ClearQuest
– XSL
– XML
– SQL
– RSS
 Tools
– Java
– Internationalization – RSA
– JavaScript
– Security
– PHP
– Logging
– Flash
– Backup
– UML
15
 Best practices
– Portfolio
Manager
– RequisitePro
– Tester
© 2005 IBM Corporation
IBM Rational
Alternative programming models
 Game developer
 High performance computing
 Command and control
 Artificial intelligence
 Domain-specific frameworks
–…
Handbook of Software Architecture, http://www.booch.com/architecture
16
© 2005 IBM Corporation
IBM Rational
A system is shaped by a myriad of
design decisions by different stakeholders
that work to balance the forces
swirling around the system
17
© 2005 IBM Corporation
IBM Rational
Forces in civil architecture
Load
Kinds of loads
- Dead loads
- Live loads
- Dynamic loads
Compression
Tension
Avoiding failure
- Safety factors
- Redundancy
- Equilibrium
Load
Any time you depart from established practice, make ten times the
effort, ten times the investigation. Especially on a very large project.
- LeMessuier
18
© 2005 IBM Corporation
IBM Rational
Forces on software
QuickTime™ and a
TIFF (LZW) decompressor
are needed to see this picture.
19
© 2005 IBM Corporation
IBM Rational
Why is software inherently complex?
 Complexity of the problem domain
 Difficulty of managing the development process
 Fluidity of software
 Fundamental challenges of discrete systems
20
© 2005 IBM Corporation
IBM Rational
Complexity of the problem domain
 Volume of requirements
 Presence of competing/contradictory requirements
 Non-functional requirements that push the limits of software
 Requirements churn
 Difficulty of communicating requirements
 Impedance mismatch among stakeholders
 Unrestrained external complexity
 Software drag
21
© 2005 IBM Corporation
IBM Rational
The limits of software
22
© 2005 IBM Corporation
IBM Rational
Difficulty of managing the development process
 Software as a team sport
 Presence of multiple languages, platforms,
processes, architectures, and tools
 Issues of scalability
 Technology churn
23
© 2005 IBM Corporation
IBM Rational
Scalability
 Size up
– Increasing database size by a factor of x increases query response
time by at most a factor of x.
 Speed up
– Increasing the capacity of your hardware configuration by a factor of x
decreases your query response time by no less than a factor of x.
 Scale up
– Increasing the workload on your system by a factor of x while
maintaining response time and/or throughput requires increasing your
capacity by a factor of no more than x.
 Scale out
– Increasing workers by a factor of x requires replicating your capacity
by a factor of at most x.
http://www.intelligententerprise.com/db_area/archives/1999/991602/scalable.jhtml
24
© 2005 IBM Corporation
IBM Rational
Fluidity of software
 Software springs from pure thought and is
intrinsically malleable, yet it can be made manifest
in our hardware systems, limited only by our
vision (and certain immutable laws of physics and
software)
25
© 2005 IBM Corporation
IBM Rational
Fundamental challenges of discrete systems
 Non-continuous behavior of discrete systems
 Combinatorial explosion of states
 Corruption from unexpected external events
 Lack of mathematical tools and intellectual
capacity to model the behavior of large discrete
systems
26
© 2005 IBM Corporation
IBM Rational
Essential complexity
 “Einstein argued that there must be simplified
explanations of nature, because God is not
capricious or arbitrary. No such faith comforts the
software engineer. Much of the complexity that he
must master is arbitrary complexity.” [Brooks]
 We may master essential complexity, but we can
never make it go away.
27
© 2005 IBM Corporation
IBM Rational
Measuring complexity of biological systems
(syntactic)
 Kolmogorov
 Entropy
 Mean component size
 Number of behaviors exhibited
 Species richness, relative to tolerance to risk
 Species guilds
 Energy flow
 Grammatical complexity
 Number of feedback loops
 Cyclomatic measures (arcs, vertices, and components)
 Graph complexity
 Hamming distance
http://www.carleton.ca/~hmasum/complex.html
28
© 2005 IBM Corporation
IBM Rational
Measuring complexity of biological systems
(semantic)
 Wordcount of description
 Minimal description length (Rissanen)
 Measure of environmental knowledge
 Evolvability
 Eigenbasis/measure of survivable environmental
states
 Program complexity
http://www.carleton.ca/~hmasum/complex.html
29
© 2005 IBM Corporation
IBM Rational
Measuring complexity of software-intensive
systems
 Kolmogorov
– Relative size of a program capable of generating a given
string
 Entropy
– Enumeration of states and transitions
http://cscs.umich.edu/~crshalizi/notebooks/complexity-measures.html
30
© 2005 IBM Corporation
IBM Rational
Measuring simplicity
 If we don’t know how to measure complexity, it is
reasonable to suggest that we don’t know how to
measure simplicity
 “I can’t define it, but I know it when I see it.”
[Supreme Court Justice Brennan]
31
© 2005 IBM Corporation
IBM Rational
Beauty
 Elegance is not an approach to finding a solution
to a problem, it is the label we stick on the
optimum solution
 Elegance is doing the most with the least
 Elegance means simplicity and less new code.
 An elegant solution solves the whole problem."
[Fisher, p. 37]
Fisher & Gipson, “In Search of Elegance”
32
© 2005 IBM Corporation
IBM Rational
Triggers of complexity
 Significant interactions
 High number of parts and degrees of freedom
 Nonlinearity
 Broken symmetry
 Nonholonomic constraints
– Localized transient anarchy
Flood, et al, Dealing with Complexity
33
© 2005 IBM Corporation
IBM Rational
Attributes of a complex system
 “Frequently, complexity takes the form of a
hierarchy, whereby a complex system is
composed of interrelated subsystems that have in
turn their own subsystems, and so on, until some
lowest level of elementary components is
reached.” [Courtois]
 Hierarchic systems are decomposable if they can
be divided into identifiable parts; they are nearly
decomposable if their parts are not completely
independent. [Simon]
34
© 2005 IBM Corporation
IBM Rational
Attributes of a complex system
 The choice of what components in a system are
primitive is relative arbitrary and is largely up to
the discretion of the observer of the system.
 As systems evolve, objects that we once
considered complex become the primitive objects
upon which more complex systems are built.
35
© 2005 IBM Corporation
IBM Rational
Attributes of a complex system
 Intracomponent linkages are generally stronger
than intercomponent linkages. This fact has the
effect of separating the high-frequency dynamics
of the components – involving the internal
structure of the components – from the lowfrequency dynamics - involving interaction among
components. [Simon]
36
© 2005 IBM Corporation
IBM Rational
Attributes of a complex system
 Hierarchic systems are usually composed of only
a few different kinds of subsystems in various
combinations and arrangements. [Simon]
37
© 2005 IBM Corporation
IBM Rational
Decomposible and nearly-decomposible systems
 Vertically, the components of a complex system
tend to be organized in increasing layers of
abstraction
 Horizontally, the components of a complex system
tend to be clustered according to frequency
 Both vertically and horizontally, the most resilient
systems tend to exhibit loose coupling and tight
cohesion among components
Simon, The Organization of Complex Systems
38
© 2005 IBM Corporation
IBM Rational
Components
 Loosely-coupled components adapt more easily to change
 Loosely-coupled components permit time- and space-separation of
processing
 Overall flexibility can be enhanced by limiting the number of
different kinds of components in the system (the system’s
alphabet)
 Alphabets are necessary but insufficient
 Complex systems also require common languages, defining
semantics of structural organization of alphabetic elements and
interactional behavior among structures
Simon, The Organization of Complex Systems
39
© 2005 IBM Corporation
IBM Rational
Languages
 Must have sufficient variety in its primitive
processes so that no meaning is absolutely
excluded from expression
 Must have sufficient flexibility in its rules of
combination so that any nuance can be expressed
by building up composite structures
Simon, The Organization of Complex Systems
40
© 2005 IBM Corporation
IBM Rational
Attributes of complex systems
 Complex systems will evolve from simple systems
much more rapidly if there are stable intermediate
forms than if there are not. [Simon]
 A complex system that works is invariable 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. [Gall]
41
© 2005 IBM Corporation
IBM Rational
Complex adaptive systems
 Emergent behavior
 Attributes
– Classification of components
– Identity of objects
– Non-linearity of behavior
– Flow of objects
– Diversity
– Use of internal models
– Clustering
Holland, Hidden Order
42
© 2005 IBM Corporation
IBM Rational
Characteristics of self-organizing systems
 Dynamic, requiring continual interactions among
lower-level components to produce and maintain
structure
 Exhibit bifurcation leading to multistable systems
– Strange attractors
Sante Fe Institute
43
© 2005 IBM Corporation
IBM Rational
Self-organization in biological systems
 Pattern formation in slime molds
 Feeding aggregation of bark beetles
 Synchronized flashing among fireflies
 Fish schooling
 Nectar source selection by honey bees
 Trail formation in ants
 Swarm raids of army ants
 Colony thermoregulation in honey bees
 Comb patterns in honey bee colonies
 Wall building by ants
 Termite mount building
 Construction Aagorithms by wasps
 Dominance hierarchies in paper wasps
Camazine, et al, Self-Organization in Biological Systems
44
© 2005 IBM Corporation
IBM Rational
Creating order in biological systems
 Self-organization
– Emergence of patterns at the global level solely from numerous
interactions among lower-level components of the system, the
rules for which are executed using only local information
 Imposed organization
– Direction from a supervisory leader
– Organic blueprints or recipes
– Patterns in the environment
Camazine, et al, Self-Organization in Biological Systems
45
© 2005 IBM Corporation
IBM Rational
Complexity, Functionality, and Understandability
Understandability
Functionality
Complexity
46
© 2005 IBM Corporation
IBM Rational
Fundamentals never go out of style
47
© 2005 IBM Corporation
IBM Rational
Shearing layers of change
Space plan
Services
Stuff
Structure
Skin
Site
Brand, How Buildings Learn
48
© 2005 IBM Corporation
IBM Rational
Fundamentals of well-engineered softwareintensive systems
 Crisp abstractions
 Clear separation of concerns
 Balanced distribution of responsibilities
 Simplicity via common abstractions and
mechanisms
49
© 2005 IBM Corporation
IBM Rational
Abstraction
 All abstractions are context-dependent
 All non-trivial abstractions are, to some degree,
leaky (and leaky abstractions are problematic).
[Joel on Software]
 There is no such thing as a perfect abstraction
– Perfect is the enemy of good enough
50
© 2005 IBM Corporation
IBM Rational
Worse Is Better
 Simplicity is the most important consideration in a
design.Both implementation and interface must be simple,
though it is more important for the implementation to be
simple.
 The design must be correct in all observable aspects; it is
slightly better to be simple than correct.
 The design must not be overly inconsistent; it is better to
drop those parts of the design that deal with less common
circumstances than to introduce implementational
complexity.
 The design must cover as many imporatant situations as
practical; completeness can be sacrificed in favor of any
other quality.
Gabrial, “Worse is Better”
51
© 2005 IBM Corporation
IBM Rational
Loose abstractions
 Over-engineering a solution is the most common
approach to dealing with complexity, yet it
typically leads to total implosion.
 Software which is flexible, simple, sloppy, tolerant
and altogether forgiving turns out to be most
resilient. [Bosworth]
52
© 2005 IBM Corporation
IBM Rational
The entire history of software engineering
Is one of rising levels of abstraction
Languages: Assembly -> Fortran/COBOL -> Simula -> C++ -> Java
Platforms: Naked HW -> BIOS -> OS -> Middleware -> Domain-specific
Processes: Waterfall -> Spiral -> Iterative -> Agile
Architecture: Procedural -> Object Oriented -> Service Oriented
Tools: Early tools -> CLE -> IDE -> XDE -> CDE
Enablement: Individual -> Workgroup -> Organization
53
© 2005 IBM Corporation
IBM Rational
Attacking complexity
 Fundamentals
– Crisp abstractions
– Clear separation of concerns
– Balanced distribution of responsibilities
– Simplicity via common abstractions and mechanisms
 Relax a constraint
 Make assumptions
54
© 2005 IBM Corporation
IBM Rational
Architecture defined
 Architecture n (1563)
– The art or science of building or constructing edifices of any
kind for human use
– The action or process of building
– Architectural work; structure, building
– The special method of ‘style’ in accordance with which the
details of the structure and ornamentation of a building are
arranged
– Construction or structure generally
– The conceptual structure and overall logical organization of a
computer or computer-based system from the point of view of
its use or design; a particular realization of this
Oxford English Dictionary, 2nd ed.
55
© 2005 IBM Corporation
IBM Rational
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
– New manufacturing processes
56
© 2005 IBM Corporation
IBM Rational
Software-intensive system
 A system in which software is the dominant, essential, and
indispensable element
– E-commerce system
– IT (business) system
– Telephone switch
– Flight control system
– Real-time control system (e.g. industrial robot)
– Sophisticated weapons system
– Software development tools
– System software (e.g. operating systems or compilers)
57
© 2005 IBM Corporation
IBM Rational
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
58
© 2005 IBM Corporation
IBM Rational
Architecture defined
 Software architecture is what software architects
do
Beck
59
© 2005 IBM Corporation
IBM Rational
Architecture defined
 Perry and Wolf, 1992
– A set of architectural (or design) elements that have a particular form
 Boehm et al., 1995
– A software system architecture comprises
• A collection of software and system components, connections, and
constraints
• A collection of system stakeholders' need statements
• A rationale which demonstrates that the components, connections, and
constraints define a system that, if implemented, would satisfy the collection
of system stakeholders' need statements
 Clements et al., 1997
–The software architecture of a program or computing system is the structure or
structures of the system, which comprise software components, the externally
visible properties of those components, and the relationships among them
http://www.sei.edu/architecture/definitions.html
60
© 2005 IBM Corporation
IBM Rational
Common elements
 Architecture defines major components
 Architecture defines component relationships (structures) and
interactions
 Architecture omits content information about components that
does not pertain to their interactions
 Behavior of components is a part of architecture insofar as it can
be discerned from the point of view of another component
 Every system has an architecture (even a system composed of one
component)
 Architecture defines the rationale behind the components and the
structure
 Architecture definitions do not define what a component is
 Architecture is not a single structure -- no single structure is the
architecture
61
© 2005 IBM Corporation
IBM Rational
Architecture defined
 Architecture establishes the context for design
and implementation
architecture
design
implementation
CODE
62
Architectural decisions are the
most fundamental decisions;
changing them will have
significant ripple effects.
© 2005 IBM Corporation
IBM Rational
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
Booch, Kruchten, Reitman, Bittner, and Shaw
63
© 2005 IBM Corporation
IBM Rational
Architecture defined
 Software architecture also involves
– Functionality
– Usability
– Resilience
– Performance
– Reuse
– Comprehensibility
– Economic and technology constraints and tradeoffs
– Aesthetic concerns
64
© 2005 IBM Corporation
IBM Rational
Architectural style defined
 Style is the classification of a system’s
architecture according to those with similar
patterns
 A pattern is a common solution to a common
problem; patterns may be classified as idioms,
mechanisms, or frameworks
65
© 2005 IBM Corporation
IBM Rational
Model, views, concerns, and stakeholders
 A model is a simplification of reality, created in order to
better understand the system being created; a semantically
closed abstraction of a system
 A view is a representation of a whole system from the
perspective of a related set of concerns
 A concern is 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
 A stakeholder is an individual, team, or organization (or
classes thereof) with interests in, or concerns relative to, a
system
66
© 2005 IBM Corporation
IBM Rational
Stakeholders and views
 Architecture is many things to many different stakeholders
– End user
– Customer
– Sys admin
– Project manager
– System engineer
– Developer
– Architect
– Maintainer
– Tester
– Other systems
 Multiple realities, multiple views and multiple blueprints exist
67
© 2005 IBM Corporation
IBM Rational
Representing software architecture
Logical View
End-user
Functionality
Implementation View
Use Case View
Process View
Programmers
Configuration management
Deployment View
System integrators
Performance
Scalability
Throughput
Conceptual
System engineering
System topology
Communication
Provisioning
Physical
Clements, et al, Documenting Software Architectures
68
© 2005 IBM Corporation
IBM Rational
Adapting views
 Not all systems require all views
– Single process (ignore process view)
– Small program (ignore implementation view)
– Single processor (ignore deployment view)
 Some systems require additional views
– Data view
– Security view
– Other aspects
69
© 2005 IBM Corporation
IBM Rational
Logical view
 The view of a system’s architecture that encompasses the
vocabulary of the problem and solution space, the
collaborations that realize the system’s use cases, the
subsystems that provide the central layering and
decomposition of the system, and the interfaces that are
exposed by those subsystems and the system as a whole
 Focuses on
– Functionality
– Key Abstractions
– Mechanisms
– Separation of concerns and distribution of responsibilities
70
© 2005 IBM Corporation
IBM Rational
Process view
 The view of a system’s architecture that
encompasses the threads and processes that
form the system’s concurrency and
synchronization mechanisms
 Focuses on
– Performance
– Scalability
– Throughput
71
© 2005 IBM Corporation
IBM Rational
Implementation view
 The view of a system's architecture that
encompasses the components used to assemble
and release the physical system
 Focuses on
– Configuration management
72
© 2005 IBM Corporation
IBM Rational
Deployment view
 The view of a system’s architecture that
encompasses the nodes that form the system’s
hardware topology on which the system executes
 Focuses on
– Distribution
– Communication
– Provisioning
73
© 2005 IBM Corporation
IBM Rational
Use case view
 The view of a system’s architecture that
encompasses the use cases that describe the
behavior of the system as seen by its end users
and other external stakeholders
74
© 2005 IBM Corporation
IBM Rational
Relations among views
Logical view
Implementation view

Process view

Deployment view
75
© 2005 IBM Corporation
IBM Rational
Architecture metamodel
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
76
© 2005 IBM Corporation
IBM Rational
Architecture metamodel
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
77
© 2005 IBM Corporation
IBM Rational
Architecture metamodel
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
78
© 2005 IBM Corporation
IBM Rational
The architecture of biological systems
 Gene
 Cell component
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
 Cell
 Tissue
 Organ
 System
79
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and a
TIFF (Uncompressed) decompressor
are needed to see this picture.
© 2005 IBM Corporation
IBM Rational
Cross-cutting concerns in biological systems
 Gene
– Reproduction
– Protein creation
 Cell component (mitochondria)
– Metabolism
– Glutamate-mediated excitotic neurlogical injury
– Cellular proliferation
– Regulation of the cellular redox state
– Heme synthesis
– Heat production
80
© 2005 IBM Corporation
IBM Rational
Cross-cutting concerns in biological systems
 Cell
– Structure
– Metabolism
– Reproduction
– Protein synthesis
– Transport/container
 Tissue
– Structure
– Work
– Transport/container
81
© 2005 IBM Corporation
IBM Rational
Cross-cutting concerns in biological systems
 Organ (liver)
– Digestion
– Carbohydrate metabolism
– Glucoenogenesis
– Glycogenesis
– Breakdown of insulin
– Lipid metabolism
– Cholesterol synthesis
– Production of triglycerides
– Coagulation factors
– Neutralization of various products
– Storage of glucose and various vitamins
– Red cell production for the fetus
 System (circulatory)
– Transport
– Heat regulation
– Healing mechanism
82
© 2005 IBM Corporation
IBM Rational
The reification of concerns
 Concerns are not isomorphic to structure
 In biological systems, these aspects evolved
simultaneously and interdependently at each level
of abstraction
– They existed a priori as reactions to evolutionary forces
– Post hoc we can name them
83
© 2005 IBM Corporation
IBM Rational
Representing software architecture
Logical View
End-user
Functionality
Implementation View
Use Case View
Process View
Programmers
Configuration management
Deployment View
System integrators
Performance
Scalability
Throughput
Conceptual
System engineering
System topology
Communication
Provisioning
Physical
Clements, et al, Documenting Software Architectures
84
© 2005 IBM Corporation
IBM Rational
Cross-cutting concerns in software-intensive
systems
 Some structures and behaviors crosscut components
•
•
•
•
Security
Concurrency
Caching
Persistence
 Such elements usually appear as small code fragments
sprinkled throughout a system
 Such elements are hard to localize using traditional
approaches
85
© 2005 IBM Corporation
IBM Rational
The role of aspect-oriented software development
 Remember the fundamentals
– Crisp abstractions
– Clear separation of concerns
– Balanced distribution of responsibilities
– Simplicity via common abstractions and mechanisms
 The current sweet spot for aspects involves elements of
each of these fundamentals
– Especially with regard to building crisp abstractions and the
separation of concerns for roles relative to packaging
– This impacts primarily the interplay of the logical view and the
use case view
86
© 2005 IBM Corporation
IBM Rational
What’s missing/what’s next
 Remember the already complex programming model
– Don’t make it more complex by adding yet another orthogonal
mechanism
 The current pragmatic focus is upon transformation tools
that focus on already visible artifacts
– The harder focus - plus the one that is most disruptive yet most
potentially valuable - is upon transformation tools that focus on
deep semantic representations and then the creation of these
traditional artifacts by reflection
• I.e. source code as a pretty-printed side-effect, not a central object
87
© 2005 IBM Corporation
IBM Rational
Summary
 This stuff is fundamentally, wickedly hard
– And it’s not going to get any better in my lifetime
• And I plan on having a long life
 Remember that the world doesn’t need Yet More
Technology
– We need less
• And ultimately, the best technology is invisible
88
© 2005 IBM Corporation
IBM Rational
Bibliography on complexity
Allen, T. & Starr, T., Hierarchy: Perspectives for Ecological Complexity, University of
Chicago: 1982.
Axelrod, R., The Complexity of Cooperation, Princeton: 1997.
Barrow, J., Davies, P., & Harper, C., Science and Ultimate Reality, Cambridge
University Press: 2004.
Bowker, G. & Star, S., Sorting Things Out: Classification and its Consequences, MIT
Press: 1999.
Buchanan, M., Nexus, Norton: 2002.
Camazine, S., Deneubourg, J., Franks, N., Sneyd, J., Theraulaz, G., & Bonabeau,
E., Self-Organization in Biological Systems, Princeton: 2001.
Duda, R., Pattern Classification, 2nd ed., Wiley: 2001.
Epxtein, J. & Axtell, R., Growing Artificial Societies, MIT Press: 1996.
Flood, R. & Carson, E., Dealing With Complexity: An Introduction to the Theory and
Application of Systems Science, Plenum Press: 1988.
Gleick, J., Chaos: Making a New Science, Penguin Books: 1987.
Hollland, J., Hidden Order, Perseus Books: 1995.
Johnson, S., Emergence, Scribner: 2001.
89
© 2005 IBM Corporation
IBM Rational
Biography on complexity
Kauffman, S., At Home in the Universe, Oxford University Press: 1995.
Kipfer, B., The Order of Things, MJF Books: 2001.
Lakoff, G., Women, Fire, and Dangerous Things: What Categories Reveal about the
Mind, University of Chicago: 1987.
Lakoff, G. & Johnson, M., Metaphors We Live By, University of Chicago: 1980.
Markman, E., Categorization and Naming in Children, MIT Press: 2002.
Nicolis, G. & Prigogine, I., Exploring Complexity, Freeman: 1989.
Pattee, H., Hierarchy Theory: The Challenge of Complex Systems, George Braziller:
1973.
Prigogine, I., The End of Certainty, Free Press: 1996.
Simon, H., The Sciences of the Artificial, 2nd ed., MIT Press: 1969.
Waldrop, M., Complexity: The Emerging Science at the Edge of Order and Chaos,
Simon & Schuster: 1992.
90
© 2005 IBM Corporation
IBM Rational
Thank you!
91
© 2005 IBM Corporation

similar documents