Embed Size (px)
Citation preview
Giovanni Asproni email: [email protected] [email protected] twitter: @gasproni linkedin: http://www.linkedin.com/in/gasproni
Creating An Incremental Architecture For Your System
OOP Conference 2017, Munich
Photo from: https://commons.wikimedia.org/wiki/File:Grady_Booch,_CHM_2011_2_cropped.jpg
“all architecture is design, but not all design is architecture”
http://handbookofsoftwarearchitecture.com/?s=all+architecture+is+design&searchsubmit=
http://handbookofsoftwarearchitecture.com/?p=63
“Every software-intensive system has an architecture. In some cases that architecture is intentional, while in others it is accidental […] the architecture of a system is the naming of the most significant design decisions that shape a system, where we measure significant by cost of change and by impact upon use.”
Photo from: https://commons.wikimedia.org/wiki/File:Grady_Booch,_CHM_2011_2_cropped.jpg
“Cost of change” is a relative value
“Impact upon use” is about how much the users of the system are affected
Architecture Is For
• Making structural choices which are costly or difficult to change once implemented
• Recording and communicating decisions
• Guiding implementation decisions
• Splitting work among teams
“incremental design (also called evolutionary design) allows you to build technical infrastructure (such as domain models and persistence frameworks) incrementally, in small pieces, as you deliver stories”
Incremental Architecture Approaches
• Emergent (TDD)
• Rough Upfront Design (RUFD)From
: https://
Incremental Architecture
• One small feature at a time • Design • Implement • Test • Deploy • Rinse and repeat
Why?
• Uncertainty due to
• Limited upfront information
• Business needs changing rapidly
• Built to change vs built to last
• Wide stakeholder community
• Limited budget
Why Not Big Upfront Design?
• Uncertainty due to
• Limited upfront information
• Business needs changing rapidly
• Built to change vs built to last
• Wide stakeholder community
• Limited budget
In software, the chances of success of a big upfront design are inversely proportional to the size of the system being designed.
So what? We already do incremental design!
BUFD Is Not The Problem
• The problems are –Speculative Upfront Design (SUFD) –Absence of refactoring
Start Small!
“A complex system that works is invariably found to have evolved from a simple system that worked.”
Travel light!
Focus On What You Know
• No SUFD • Sufficient design • Remove “reusable” and “flexible”
from your dictionary
“Favoring simplicity before generality acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality.”
Kevlin Henney
“Choose Your Tools With Care”
Giovanni Asproni
Walking Skeleton
From: http://alistair.cockburn.us/Walking+skeleton
“is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.”
DatabaseServerClientWalking skeleton
Skeleton On Crutches
DatabaseServerClientWalking skeleton
Filesystem
https://gojko.net/2014/06/09/forget-the-walking-skeleton-put-it-on-crutches/
http://www.developerdotstar.com/mag/articles/reeves_design.html
“Coding actually makes sense more often than believed. Often the process of rendering the design in code will reveal oversights and the need for additional design effort. The earlier this occurs, the better the design will be.”
Jack Reeves, “What Is Software Design?”
Design for testability
“When testing is done right, it is almost unreasonably effective at uncovering defects that matter.”
John Regehr
http://blog.regehr.org/archives/820
“BDUF design for testability is hard because it is difficult to know what the tests will need in the way of control points and observation points on the SUT. We can easily build software that is difficult to test. We can also spend a lot of time designing in testability mechanisms that are either insufficient or unnecessary. Either way, we will have spent a lot of effort with nothing to show for it.”
TDD at all levels helps
Write a failing acceptance test
Write a failing unit test
Make the test pass
Refactor
Create Feedback Loops
• Continuous Integration
• Continuous Deployment
• Continuous Delivery
Main Architectural Drivers: Qualities
Scalability
Throughput
Latency
Usability
Testability
Security
Maintainability
Supportability
Diagnosability
…
Qualities
© Benedetto Bufalino http://www.designboom.com/art/benedetto-bufalino-transforms-a-car-into-a-cardboard-ferrari-10-31-2013/
• Have to be baked-in – They cannot easily be
retrofitted
Often Forgotten Things
• Buildability • Deployability • Configurability • Versioning strategies
How can I include architectural tasks in my workflow?
• Architecture in the Backlog • Architectural Trigger • Architectural Spike • Technical Debt Management
Patterns
Document After The Fact!IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-12, NO.2, FEBRUARY 1986 251
A Rational Design Process: How and Why to Fake ItDAVID LORGE PARNAS AND PAUL C. CLEMENTS
Abstract-Many have sought a software design process that allows aprogram to be derived systematically from a precise statement of re-quirements. This paper proposes that, although we will not succeed indesigning a real product in that way, we can produce documentationthat makes it appear that the software was designed by such a process.We first describe the ideal process, and the documentation that it re-quires. We then explain why one should attempt to design according tothe ideal process and why one should produce the documentation thatwould have been produced by that process. We describe the contents ofeach of the required documents.
Index Terms-Programming methods, software design, softwaredocumentation, software engineering.
I. THE SEARCH FOR THE PHILOSOPHER'S STONE: WHY
Do WE WANT A RATIONAL DESIGN PROCESS?
A PERFECT LY rational person is one who always hasa good reason for what he does. Each step taken can
be shown to be the best way to get to a well defined goal.Most of us like to think of ourselves as rational profes-sionals. However, to many observers, the usual process ofdesigning software appears quite irrational. Programmersstart without a clear statement of desired behavior and im-plementation constraints. They make a long sequence ofdesign decisions with no clear statement of why they dothings the way they do. Their rationale is rarely explained.
Many of us are not satisfied with such a design process.That is why there is research in software design, program-ming methods, structured programming, and related top-ics. Ideally, we would like to derive our programs from astatement of requirements in the same sense that theoremsare derived from axioms in a published proof. All of themethodologies that can be considered "top down" are theresult of our desire to have a rational, systematic way ofdesigning software.
This paper brings a message with both bad news andgood news. The bad news is that, in our opinion, we willnever find the philosopher's stone. We will never find aprocess that allows us to design software in a perfectlyrational way. The good news is that we can fake it. Wecan present our system to others as if we had been rationaldesigners and it pays to pretend do so during developmentand maintenance.
Manuscript received March 18, 1985. This work was supported by theU.S. Navy and by the National Science and Engineering Research Council(NSERC) of Canada.
D. L. Parnas is with the Department of Computer Science, Universityof Victoria, Victoria, B. C. V8W 2Y2, Canada, and the Computer Scienceand Systems Branch, Naval Research Laboratory, Washington, DC 20375.
P. C. Clements is with the Computer Science and Systems Branch, NavalResearch Laboratory, Washington, DC 20375.
IEEE Log Number 8405736.
II. WHY WILL A SOFTWARE DESIGN "PROCESS"
ALWAYS BE AN IDEALIZATION?
We will never see a software project that proceeds inthe "rational" way. Some of the reasons are listed below:
1) In most cases the people who commission the build-ing of a software system do not know exactly what theywant and are unable to tell us all that they know.
2) Even if we knew the requirements, there are manyother facts that we need to know to design the software.Many of the details only become known to us as we pro-gress in the implementation. Some of the things that welearn invalidate our design and we must backtrack.Be-cause we try to minimize lost work, the resulting designmay be one that would not result from a rational designprocess.
3) Even if we knew all of the relevant facts before westarted, experience shows that human beings are unableto comprehend fully the plethora of details that must betaken into account in order to design and build a correctsystem. The process of designing the software is one inwhich we attempt to separate concerns so that we areworking with a manageable amount of information. How-ever, until we have separated the concerns, we are boundto make errors.
4) Even if we could master all of the detail needed, allbut the most trivial projects are subject to change for ex-ternal reasons. Some of those changes may invalidate pre-vious design decisions. The resulting design is not onethat would have been produced by a rational design pro-cess.
5) Human errors can only be avoided if one can avoidthe use of humans. Even after the concerns are separated,errors will be made.
6) We are often burdened by preconceived design ideas,ideas that we invented, acquired on related projects, orheard about in a class. Sometimes we undertake a projectin order to tryout or use a favorite idea. Such ideas maynot be derived from our requirements by a rational pro-cess.
7) Often we are encouraged, for economic reasons, touse software that was developed for some other project. Inother situations, we may be encouraged to share our soft-ware with another ongoing project. The resulting softwaremay not be the ideal software for either project, i.e., notthe software that we would develop based on its require-ments alone, but it is good enough and will save effort.
For all of these reasons, the picture of the software de-signer deriving his design in a rational, error-free wayfrom a statement of requirements is quite unrealistic. No
0098-5589/86/0200-0251$01.00 © 1986 IEEE
Brownfield And Legacy Systems
• Rewrite from scratch rarely works
• The previous approach still apply
Books
ptg6985396
From the Library of Giovanni Asproni
ptg6985396
From the Library of Giovanni Asproni
