JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures
Rediscovering modularity - JavaOne Brazil 2012
123
Rediscovering Modularity Chris Chedgey Structure101 @chedgey JavaOne Brazil December 2012
-
Upload
chris-chedgey -
Category
Technology
-
view
105 -
download
0
description
Similar to previous talks, but I added some slides at the end to represent the demos.
Transcript of Rediscovering modularity - JavaOne Brazil 2012
Rediscovering Modularity Chris Chedgey Structure101 @chedgey JavaOne Brazil December 2012
Architecture
Modularity
Structure
Mud
• defined, communicated, enforced
• interfaces, responsibility
• encapsulation, coupling
•
Modularity Manage complexity
by
Encapsulation
Abstraction
Modularity Manage complexity
by
Encapsulation
Abstraction
Interface/hiding
Modularity Manage complexity
by
Encapsulation
Abstraction
Interface/hiding
Cohesion
Modularity Manage complexity
by
Encapsulation
Abstraction
Interface/hiding
Cohesion
Clear responsibility
Modularity Manage complexity
by
Encapsulation
Abstraction
Interface/hiding
Cohesion
Coupling Clear responsibility
Modularity Manage complexity
by
Encapsulation
Encapsulation Abstraction
Interfaces/hiding
Cohesion
Coupling Clear responsibility
Encapsulation Abstraction
Interfaces/hiding
Cohesion
Coupling Clear responsibility
Modularity
Composition
Complexity
Composition
Complexity
Cyclomatic
Complexity
(CC)
Encapsulation Abstraction
Interface/hiding
Cohesion
Coupling Clear responsibility
Encapsulation Abstraction
Interface/hiding
Cohesion
Coupling Clear responsibility
Modularity
Composition
Complexity
Cyclomatic
Complexity
(CC)
Composition
Complexity
Compositional
Complexity
(CC)
Encapsulation Abstraction
Interface/hiding?
Cohesion
Coupling?
Clear responsibility
Encapsulation Abstraction
Interface/hiding?
Cohesion
Coupling?
Clear responsibility
Modularity?
Composition
Complexity
Compositional
Complexity
(CC)
Composition
Complexity
Compositional
Complexity
(CC)
Hierarchical
=> Scalable
Coupling
Coupling
Dependencies
Dependencies
Dependencies
“Tangles”
“Tangles”
=
Not scalable!!
Ideally…
Ideally…
Start with a loose “architecture”
Ideally…
Start with a loose “architecture”
Let suitable architecture emerge, without “baggage”
At some point stronger, higher-level abstractions are needed
(~50Kloc – Martin, Foote)
Restructure to defined architecture
Iterate with development
Strengthen with growth
Ideally…
Start with a loose “architecture”
Let suitable architecture emerge, without “baggage”
Ideally…
Start with a loose “architecture”
Let suitable architecture emerge, without “baggage”
At some point stronger, higher-level abstractions are needed
(~50Kloc – Martin, Foote)
Ideally…
Start with a loose “architecture”
Let suitable architecture emerge, without “baggage”
At some point stronger, higher-level abstractions are needed
(~50Kloc – Martin, Foote)
Restructure to defined architecture
Ideally…
Start with a loose “architecture”
Let suitable architecture emerge, without “baggage”
At some point stronger, higher-level abstractions are needed
(~50Kloc – Martin, Foote)
Restructure to defined architecture
Iterate with development
Ideally…
Start with a loose “architecture”
Let suitable architecture emerge, without “baggage”
At some point stronger, higher-level abstractions are needed
(~50Kloc – Martin, Foote)
Restructure to defined architecture
Iterate with development
Strengthen with growth
0.7.2
Mar „04
0.8.6
Oct „04
0.8.7
Apr „05
Erosion
“Sometimes the developers manage to maintain this purity of design through the initial development and into the first release. More often something goes wrong. The software starts to rot like a piece of bad
meat.”
Bob Martin, “Agile Software Development”
0.8.8
May „05
1.0.0
Jun „06
1.3.0
Nov „07
1.3.5
Sep „08
Cost…
Cost…
Miserable developers
Cost…
Miserable developers
Cost per feature increases
Cost…
Miserable developers
Cost per feature increases
Unexpected impacts of change
Cost…
Miserable developers
Cost per feature increases
Unexpected impacts of change
Unreliable schedules
Cost…
Miserable developers
Cost per feature increases
Unexpected impacts of change
Unreliable schedules
Test cycles increase
Cost…
Miserable developers
Cost per feature increases
Unexpected impacts of change
Unreliable schedules
Test cycles increase
Reuse less
Cost…
Miserable developers
Cost per feature increases
Unexpected impacts of change
Unreliable schedules
Test cycles increase
Reuse less
Value of your code base declines
Technical Debt
Technical Debt
Abstraction
Abstraction
Abstraction
Abstraction
Abstraction
Abstraction
Abstraction
Abstraction
Refactoring Restructuring
Refactoring
• “Changing code without
modifying behavior to
improve nonfunctional
attributes.”
Restructuring
• “Reorganizing a code-base
without modifying the code to
improve modularity”
Refactoring
• “Changing code without
modifying behavior to
improve nonfunctional
attributes.”
• Code is readable
Restructuring
• “Reorganizing a code-base
without modifying the code to
improve modularity”
• Code-base is understandable
Refactoring
• “Changing code without
modifying behavior to
improve nonfunctional
attributes.”
• Code is readable
• A lot of invasive code editing
Restructuring
• “Reorganizing a code-base
without modifying the code to
improve modularity”
• Code-base is understandable
• Minimal invasive code editing
Refactoring
• “Changing code without modifying behavior to improve nonfunctional attributes.”
• Code is readable
• A lot of invasive code editing
• Scope: small worlds of a few classes at a time; what you see in the IDE.
Restructuring
• “Reorganizing a code-base without modifying the code to improve modularity”
• Code-base is understandable
• Minimal invasive code editing
• Scope: whole code base; what you don‟t see in the IDE
Retrofitting…
Retrofitting…
Physical or virtual?
Retrofitting…
Physical or virtual?
Top-down or bottom-up?
Retrofitting…
Physical or virtual?
Top-down or bottom-up?
Bust big class tangles
Retrofitting…
Physical or virtual?
Top-down or bottom-up?
Bust big class tangles
Create a structured model (levelized+CC) (use strategies)
Retrofitting…
Physical or virtual?
Top-down or bottom-up?
Bust big class tangles
Create a structured model (levelized+CC) (use strategies)
Adjust module boundaries (strengthen abstractions)
Retrofitting…
Physical or virtual?
Top-down or bottom-up?
Bust big class tangles
Create a structured model (levelized+CC) (use strategies)
Adjust module boundaries (strengthen abstractions)
Define layers, visibility
Retrofitting…
Physical or virtual?
Top-down or bottom-up?
Bust big class tangles
Create a structured model (levelized+CC) (use strategies)
Adjust module boundaries (strengthen abstractions)
Define layers, visibility
Repair violations in the implementation levels
Structure101
Restructure101
Structure101
Restructure101
Structure101
Restructure101
Structure101
Restructure code-base here …
Restructure code-base here …
…to remove
complexity
here …
Restructure code-base here …
…to remove
complexity
here …
…and create
IDE actions
here.
Detect structural debt
here…
Define visibility
and layering
rules here…
Communicate
and enforce at
edit and build
time…
Communicate
and enforce at
edit and build
time…
Architecture
Modularity
Structure
Mud
• defined, communicated, enforced
• interfaces, responsibility
• encapsulation, coupling
•
Chris Chedgey Structure101 @chedgey
Thank you!
