September 21, 2010
by CRC Press
Reference - 328 Pages - 103 B/W Illustrations
ISBN 9781439812341 - CAT# K10622
Series: Software Engineering
When the author started developing software, there were books on languages and books on object-oriented programming, but few books on design. Knowing the features of the C++ language does not mean you can design a good object-oriented system, nor does knowing the Unified Modeling Language (UML) imply you can design a good system architecture.
Setting it apart from other books about software architecture, Just Enough Software Architecture: A Risk-Driven Approach …
Teaches risk-driven architecting
The book describes a way to do just enough architecture. It avoids the "one size fits all" process tar pit with advice on how to tune your architecture and design effort based on the risks you face.
The book seeks to make architecture relevant to all software developers, not just architects.
Cultivates declarative knowledge
The book will make you more aware of what you have been doing and provide names for the concepts.
Emphasizes the engineering
The book focuses on the technical parts of software development and deals with what developers do to ensure the system works. It shows you how to build models and analyze architectures so that you can make principled design tradeoffs. It describes the techniques software designers use to reason about medium- to large-sized problems and points out where you can learn specialized techniques in more detail.
Provides practical advice
The approach in this book embraces drill-down/pop-up behavior by describing models that have various levels of abstraction, from architecture to data structure design.
1.1 Partitioning, knowledge, and abstractions
1.2 Three examples of software architecture
1.4 Perspective shift
1.5 Architects architecting architectures
1.6 Risk-driven software architecture
1.7 Architecture for agile developers
1.8 About this book
I RISK-DRIVEN SOFTWARE ARCHITECTURE
2 Software Architecture
2.1 What is software architecture?
2.2 Why is software architecture important?
2.3 When is architecture important?
2.4 Presumptive architectures
2.5 How should software architecture be used?
2.6 Architecture-indifferent design
2.7 Architecture-focused design
2.8 Architecture hoisting
2.9 Architecture in large organizations
2.11 Further reading
3 Risk-Driven Model
3.1 What is the risk-driven model?
3.2 Are you risk-driven now?
3.5 Guidance on choosing techniques
3.6 When to stop
3.7 Planned and evolutionary design
3.8 Software development process
3.9 Understanding process variations
3.10 The risk-driven model and software processes
3.11 Application to an agile processes
3.12 Risk and architectural refactoring
3.13 Alternatives to the risk-driven model
3.15 Further reading
4 Example: Home Media Player
4.1 Team communication
4.2 Integration of COTS components
4.3 Music metadata format
5 Modeling Advice
5.1 Focus on risks
5.2 Understand your architecture
5.3 Distribute architecture skills
5.4 Make rational architecture choices
5.5 Avoid Big Design Up Front
5.6 Avoid top-down design
5.7 Remaining challenges
5.8 Features and risk: a story
II ARCHITECTURE MODELING
6 Engineers Use Models
6.1 Scale and complexity require abstraction
6.2 Abstractions provide insight and leverage
6.3 Reasoning about system qualities
6.4 Models elide details
6.5 Models can amplify reasoning
6.6 Question first and model second
6.8 Further reading
7 Conceptual Model of Software Architecture
7.1 Canonical model structure
7.2 Domain, design, and code models
7.3 Designation and refinement relationships
7.4 Views of a master model
7.5 Other ways to organize models
7.6 Business modeling
7.7 Use of UML
7.9 Further reading
8 The Domain Model
8.1 How the domain relates to architecture
8.2 Concept model
8.3 Navigation and invariants
8.5 Functionality scenarios
8.7 Further reading
9 The Design Model
9.1 Design model
9.2 Boundary model
9.3 Internals model
9.4 Quality attributes
9.5 Walkthrough of Yinzer design
9.7 Dynamic architecture models
9.8 Architecture description languages
9.10 Further reading
10 The Code Model
10.1 Model-code gap
10.2 Managing consistency
10.3 Architecturally-evident coding style
10.4 Expressing design intent in code
10.5 Model-in-code principle
10.6 What to express
10.7 Patterns for expressing design intent in code
10.8 Walkthrough of an email processing system
11 Encapsulation and Partitioning
11.1 Story at many levels
11.2 Hierarchy and partitioning
11.3 Decomposition strategies
11.4 Effective encapsulation
11.5 Building an encapsulated interface
11.7 Further reading
12 Model Elements
12.1 Allocation elements
12.3 Component assemblies
12.5 Design decisions
12.6 Functionality scenarios
12.7 Invariants (constraints)
12.10 Quality attributes
12.11 Quality attribute scenarios
13 Model Relationships
13.1 Projection (view) relationship
13.2 Partition relationship
13.3 Composition relationship
13.4 Classification relationship
13.5 Generalization relationship
13.6 Designation relationship
13.7 Refinement relationship
13.8 Binding relationship
13.9 Dependency relationship
13.10 Using the relationships
13.12 Further reading
14 Architectural Styles
14.2 Platonic vs. embodied styles
14.3 Constraints and architecture-focused design
14.4 Patterns vs. styles
14.5 A catalog of styles
14.6 Layered style
14.7 Big ball of mud style
14.8 Pipe-and-filter style
14.9 Batch-sequential style
14.10 Model-centered style
14.11 Publish-subscribe style
14.12 Client-server style & N-tier
14.13 Peer-to-peer style
14.14 Map-reduce style
14.15 Mirrored, farm, and rack styles
14.17 Further reading
15 Using Architecture Models
15.1 Desirable model traits
15.2 Working with views
15.3 Improving view quality
15.4 Improving diagram quality
15.5 Testing and proving
15.6 Analyzing architecture models
15.7 Architectural mismatch
15.8 Choose your abstraction level
15.9 Planning for the user interface
15.10 Prescriptive vs. descriptive models
15.11 Modeling existing systems
15.13 Further reading
16.2 Focus on quality attributes
16.3 Solve problems, not just model them
16.4 Use constraints as guide rails
16.5 Use standard architectural abstractions
…it provides a refreshing and non-dogmatic way to approach software architecture—one with enormous practical value. … a uniquely practical and approachable contribution to the field of software architecture. For anyone who must create innovative software systems, for anyone who is faced with tough decisions about design tradeoffs, for anyone who must find an appropriate balance between agility and discipline—in short, for almost any software engineer—this is essential reading.
—From the Foreword by David Garlan, Professor, School of Computer Science and Director, Professional Software Engineering Programs, Carnegie Mellon University
This book reflects the author’s rare mix of deep knowledge of software architecture concepts and extensive industry experience as a developer. If you’re an architect, you will want the developers in your organization to read this book. If you’re a developer, do read it. The book is about architecture in real (not ideal) software projects. It describes a context that you recognize and then it shows you how to improve your design practice in that context.
—Paulo Merson, practicing software architect and Visiting Scientist at the Software Engineering Institute (SEI)
The risk-driven model approach described … has been applied to the XIM project here at the NASA Johnson Space Center with much success. … a must for all members of the project from project management to individual developers. In fact, it is a must for every developer’s tool belt. (The Code Model section and the anti-patterns alone are worth the cost of the book!). …
—Christopher Dean, Chief Architect, XIM, Engineering Science Contract Group, NASA Johnson Space Center
… George Fairbanks’ outstanding new book distills the best of the latest architecture research to provide clear, concrete, practical and actionable advice that serves as a bungee cord for those application architects ready to take the plunge and leverage new architecture best practices to improve their applications. … an important contribution to the IT application architecture literature and may well become a standard reference work for enterprise application architects.
—Dr. Ian Maung, former Senior Vice President of Enterprise Architecture, Citigroup, and Director of Enterprise Architecture, Covance
Just Enough Software Architecture will coach you in the strategic and tactical application of the tools and strategies of software architecture to your software projects. … Whether you are a developer or an architect, this book is a solid foundation and reference for your architectural endeavors.
—Nicholas Sherman, Program Manager, Microsoft
… a one-of-a-kind book. … I particularly like his idea of presenting architecture specifically as a way to deal with risks—I find this to be a key insight that makes a convincing argument for the approach illustrated by the book.
—Dr. Richard LeBlanc, Chair of Computer Science and Software Engineering Department, University of Seattle
This book presents a unique view on software architecture that makes it both accessible and practical. The concepts of just enough architecture and risk-driven design are breakthrough ideas developed by Fairbanks. … I found it extremely useful and a must-read for anyone working in software development.
—Dr. Marcus Fontoura, Principal Research Scientist and Architect, Yahoo! Research, and author of The UML Profile for Framework Architectures
…The risk-driven approach to design presented in this book helps software developers understand how much design is needed so they can quickly get back to writing code and providing value to customers in the form of working software. If you’re only going to read one book on software architecture, start with this one. …
—Michael Keeling, professional software engineer
This book directly tackles some key needs of software practitioners who seek that blend of tools to help them create more effective systems, more effectively. … an important addition to any software architecture bookshelf.
—Desmond D’Souza, author of MAp and Catalysis, Kinetium, Inc.
… it captures and concisely conveys to designers of software-intensive systems just what they need to know about today’s (sadly) buzzword-laden minefield of software architecture. … This is a worthy book, a joy to read, and one I wish I had earlier in my career … It is deserving of a place on your shelf if you want become a better software designer.
—Dr. Timothy J. Halloran, Director of Engineering, SureLogic Inc.
System and software developers questioning why and where about software architecture will appreciate the clear arguments and enlightening analogies this book presents; developers struggling with when and how to do architecture will discover just-enough guidance, along with concepts and ideas that clarify, empower, and liberate. … All in all, this book is easy to read, concise, yet rich with references—a well-architected and finely-designed book!
—Dr. Shang-Wen Cheng, Carnegie Mellon ISR alumnus and flight software engineer
… should appeal to any developers trying to work out how to make the architecting process tractable. … should help developers interested in understanding the broader theory and practice apply these concepts to their projects.
—Dr. Bradley Schmerl, Senior Systems Scientist, School of Computer Science, Carnegie Mellon University
This book shows how software architecture helps you build software instead of distracting from the job: the book lets you identify and address (only) those critical architectural concerns that would otherwise prevent you from writing code.
—Dr. Kevin Bierhoff, software engineering professional
… this book shows you how to drive your architecture design based on risks. The book gives you a risk-driven approach, and discusses good architectural practices, models, styles and techniques to create the architecture.
—Guido Zgraggen, alumnus of Carnegie Mellon’s Master of Software Engineering program