Framework Process Patterns
Lessons Learned Developing Application Frameworks
Published on 1. May 2002
Book
Paperback/Softback
256 pages
978-0-201-73132-3 (ISBN)
Description
To build effective frameworks, solid object-oriented development skills aren't enough: you need "rules of thumb" and patterns that have never appeared in any book -- until now. In this book, James Carey and Brent Carlson share the framework patterns they uncovered as architects for IBM's groundbreaking SanFrancisco and WebSphere Business Components projects. The solutions they describe cover the entire framework development process, from initial requirements gathering to teamwork to documentation. The authors begin by reviewing the role of frameworks and the techniques of conventional framework development; then introduce a running case study that presents a common domain and vocabulary for the patterns covered in this book. They then present a series of key patterns, each including descriptions, intent, context, motivation, examples, problems, solutions, tradeoffs, applicability, related patterns, and more. For all experienced software architects, software system developers, and application developers.
More details
Language
English
Place of publication
Boston
United States
Publishing group
Pearson Education (US)
Target group
College/higher education
Dimensions
Width: 236 mm
Thickness: 16 mm
Weight
523 gr
ISBN-13
978-0-201-73132-3 (9780201731323)
Copyright in bibliographic data and cover images is held by Nielsen Book Services Limited or by the publishers or by their respective licensors: all rights reserved.
Schweitzer Classification
Persons
James Carey is the Base Component (fine-grained component) architect for IBM's WebSphere Business Components. He previously served as a lead designer for the Common Business Objects and General Ledger Core Business Processes part of the IBM SanFrancisco frameworks.
Brent Carlson is Vice President of Technology for LogicLibrary, a provider of software asset management products and services. He previously served as the lead architect for the IBM SanFrancisco project and lead designer for its Warehouse and Order Management Core Business Processes.
0201731320AB04172002
Brent Carlson is Vice President of Technology for LogicLibrary, a provider of software asset management products and services. He previously served as the lead architect for the IBM SanFrancisco project and lead designer for its Warehouse and Order Management Core Business Processes.
0201731320AB04172002
Content
Preface.
Why Listen to Us?
How to Read This Book.
Acknowledgments.
1. Introduction.
What Is a Framework?
Framework Artifacts.
Developing Frameworks.
Using Frameworks.
The Framework Process Patterns.
2. Case Study.
The Clothing Management Domain.
Overview.
Selecting Clothing.
Cleaning Clothing.
Reparing Clothing.
Purchasing Clothing.
3. The Development Process.
Alles in Ordnung.
Follow a Methodical Development Process.
Innocent Questions.
Connecting Domain and Technical Experts.
Divide and Conquer.
Making the Framework Consumable.
Consistency Is King.
Maintain Consistency throughout the Framework.
Iterate, Iterate, Iterate.
Three Iterations to Validate.
Exposing It All.
A Framework's Customer Is Its Partner.
4. Requirements.
It Depends.
Identifying Customization.
Tor's Second Cousin.
How Extreme Is Too Extreme?
What, Not How.
Implementations Masquerading as Requirements.
The Stupid Test.
Include Obvious Domain Capabilities While Keeping the Framework Focused.
5. Analysis.
Eating the Elephant (One Byte at a Time).
Decomposing the Problem.
Something Is Better Than Nothing.
Document What You Know When You Know It.
Where's Mr. Spock When You Need Him?
Domain-Technical Cross-Team Communication.
6. Design.
Pass the Buck.
Knowing When a Framework Shouldn't Do Something.
Missed It by That Much.
Developing and Applying Patterns.
That's the Way the Cookie Crumbles.
Patterns Can Be Mini-Frameworks.
It's Still OO to Me.
Frameworks Aren't Exempt from Good and Bad Object-Oriented Practices.
7. Documentation.
Souvenirs.
Keeping Just Enough to Write Documentation Later.
Give 'Em What They Want.
Different Framework Audiences Have Different Needs.
8. Social Aspects.
There Is No "I" in Team.
The Importance of Team Dynamics.
The Great Communicator.
Translating between Domain and Technical Terminology and Concepts.
Consistency Czar.
Making Sure Consistency Happens.
9. Framework Use.
Just Learn It.
Using Frameworks Requires Up-Front Education.
Map Early, Map Often.
Use Frameworks by Mapping.
Color Inside the Lines.
Change Only What You Need to Change.
10. Conclusion.Appendix A. Frameworks and Components.
What Is a Component?
Fine- and Coarse-Grained Components.
Building Coarse-Grained Components.
Appendix B. The IBM SanFrancisco Frameworks Development Process.
Process Flow.
Process Artifacts.
Process Participants.
Process Step Details.
Bibliography.Index. 0201731320T04172002
Why Listen to Us?
How to Read This Book.
Acknowledgments.
1. Introduction.
What Is a Framework?
Framework Artifacts.
Developing Frameworks.
Using Frameworks.
The Framework Process Patterns.
2. Case Study.
The Clothing Management Domain.
Overview.
Selecting Clothing.
Cleaning Clothing.
Reparing Clothing.
Purchasing Clothing.
3. The Development Process.
Alles in Ordnung.
Follow a Methodical Development Process.
Innocent Questions.
Connecting Domain and Technical Experts.
Divide and Conquer.
Making the Framework Consumable.
Consistency Is King.
Maintain Consistency throughout the Framework.
Iterate, Iterate, Iterate.
Three Iterations to Validate.
Exposing It All.
A Framework's Customer Is Its Partner.
4. Requirements.
It Depends.
Identifying Customization.
Tor's Second Cousin.
How Extreme Is Too Extreme?
What, Not How.
Implementations Masquerading as Requirements.
The Stupid Test.
Include Obvious Domain Capabilities While Keeping the Framework Focused.
5. Analysis.
Eating the Elephant (One Byte at a Time).
Decomposing the Problem.
Something Is Better Than Nothing.
Document What You Know When You Know It.
Where's Mr. Spock When You Need Him?
Domain-Technical Cross-Team Communication.
6. Design.
Pass the Buck.
Knowing When a Framework Shouldn't Do Something.
Missed It by That Much.
Developing and Applying Patterns.
That's the Way the Cookie Crumbles.
Patterns Can Be Mini-Frameworks.
It's Still OO to Me.
Frameworks Aren't Exempt from Good and Bad Object-Oriented Practices.
7. Documentation.
Souvenirs.
Keeping Just Enough to Write Documentation Later.
Give 'Em What They Want.
Different Framework Audiences Have Different Needs.
8. Social Aspects.
There Is No "I" in Team.
The Importance of Team Dynamics.
The Great Communicator.
Translating between Domain and Technical Terminology and Concepts.
Consistency Czar.
Making Sure Consistency Happens.
9. Framework Use.
Just Learn It.
Using Frameworks Requires Up-Front Education.
Map Early, Map Often.
Use Frameworks by Mapping.
Color Inside the Lines.
Change Only What You Need to Change.
10. Conclusion.Appendix A. Frameworks and Components.
What Is a Component?
Fine- and Coarse-Grained Components.
Building Coarse-Grained Components.
Appendix B. The IBM SanFrancisco Frameworks Development Process.
Process Flow.
Process Artifacts.
Process Participants.
Process Step Details.
Bibliography.Index. 0201731320T04172002