Software Reuse

by Jacobson, Ivar; Griss, Martin; Jonsson, Dr. Patrik

• ISBN13: 9780201924763
• ISBN10: 0201924765
• Format: Hardcover
• Copyright: 1997-06-01
• Publisher: Addison-Wesley Professional

Summary

"How can I incorporate reuse into my complex software development process in order to gain a competitive edge?"

This is a question that many have attempted to answer by taking up object technology, with varying degrees of success. In Software Reuse: Architecture, Process and Organization for Business Success , the authors present a brand new, technically innovative, coherent and systematic model for implementing reuse. They have combined their experience in the fields of object oriented software engineering, business engineering and systematic software reuse to create the Reuse-Driven Software Engineering Business (Reuse Business) framework.

Software Reuse: Architecture, Process and Organization for Business Success

- introduces the concept of software reuse as a business success enable
- describes how the right architecture allows applications and components to evolve gracefull
- provides guidelines for implementing software engineering processe
- advises on organizational issues such as the structure, transition, day-to-day managment, economics and measurement.
 
Whether you are a software engineer, architect, designer, programmer or manager, whether you are familiar with the concepts of reuse, component-based software engineering, object oriented technology and business engineering or not, you should read Software Reuse: Architecture, Organization and Process for Business Success. In it you will find new ground-breaking information and advice

Visit the Rational Web Site http://www.rational.com

Author Biography

Dr. Ivar Jacobson,Vice President of Business Engineering, is the inventor of the OOSE method, and he is also the founder of Objectory AB in Sweden, which recently merged with Rational Software Corporation. Dr. Jacobson is the principal author of two influential and best-selling books Object-Oriented Software Engineering--A Use Case Driven Approach (Computer Language Productivity award winner in 1992) and The Object Advantage--Business Process Reengineering with Object Technology. He has also authored several widely referenced papers on object technology. One of the most famous papers is his first OOPSLA '87 paper entitled "Object-Oriented Development in an Industrial Environment," which presented the first truly object-oriented method ever published. Ivar Jacobson's use-case driven approachhas had a very strong impact on the entireOOAD industry, and he himself has become one of its "icons." Consequently, he isa frequently invited keynote speaker and panelist, debating OOAD topics withcolleagues and methodologists such as Grady Booch, Jim Rumbaugh, StevenMellor, and Rebecca Wirfs-Brock at major OO conferences around the world.

He is well known for his pioneering work and more than 20 years of experience inusing object methods for the design of large real-time systems. His earlyobject-based design technique has evolved into the international standardITU(formerly CCITT)/SDL.

Dr. Jacobson also regularly serves on the OOPSLA, ECOOP, and TOOLSprogram committees, and he is a member of the advisory board of the Journal ofObject-Oriented Programming.

In 1994, Ivar Jacobson received the first Swedish Computer Association (SCA)award (the Kjell Hultman prize) for "extraordinary achievement in promotingefficiency and productivity in the development and use of informationtechnology."

Martin Griss is a Senior Laboratory Scientist at Hewlett Packard Laboratories where, as HP's "Reuse Rabbi", he created the Corporate Reuse Program and led HP's technical contributions as co-submittor of UML to the OMG. He also writes a reuse column for Object Magazine and is active on several reuse program and steering commitees.

Patrik Jonsson works at Rational Software Corporation in Sweden as a Senior Consultant where he has been developing the architecture and method of the Objectory process with a current focus on reuse and user interface development.

0201924765AB04062001

Table of Contents

FOREWORD	vii	(2)
Bjorn Svedberg
FOREWORD	ix	(2)
Joel Birnbaum
PREFACE	xi	(9)
Systematic software reuse	xi	(1)
What is this book about?	xii	(1)
Who needs a Reuse-driven Software Engineering Business?	xiii	(1)
Our experience	xiv	(1)
How this book is organized	xv	(2)
What this book offers	xvii	(2)
Acknowledgments	xix	(1)
DEDICATIONS	xx
PART I INTRODUCING THE REUSE-DRIVEN SOFTWARE ENGINEERING BUSINESS	1	(48)
1 SOFTWARE REUSE SUCCESS FACTORS	4	(25)
1.1 Software reuse is a simple idea	6	(1)
1.2 Components are fueling a revolution in application development	7	(1)
1.3 A systematic approach makes pragmatic reuse work	8	(1)
1.4 Ericsson and Hewlett-Packard reuse experience reveals common principles	9	(6)
1.5 Reuse requires changes in process	15	(4)
1.6 Reuse requires changes in organization	19	(2)
1.7 Adopt reuse systematically and incrementally	21	(3)
1.8 Input from other reuse programs	24	(3)
1.9 It takes a set of principles	27	(1)
1.10 Summary	28	(1)
1.11 Additional reading	28	(1)
2 REUSE-DRIVEN SOFTWARE ENGINEERING IS A BUSINESS	29	(20)
2.1 Is it a business for you?	30	(2)
2.2 Make reuse cost-effective	32	(1)
2.3 A Reuse Business has business characteristics	33	(3)
2.4 Architect components and applications	36	(4)
2.5 Software engineering processes	40	(3)
2.6 Establishing and managing a reuse business	43	(5)
2.7 Summary	48	(1)
2.8 Additional reading	48	(1)
PART II ARCHITECTURAL STYLE	49	(164)
3 OBJECT-ORIENTED SOFTWARE ENGINEERING	53	(27)
3.1 Software engineering transforms requirements into code	53	(1)
3.2 Software engineering is a team process	54	(1)
3.3 Software engineering is systematic model building	55	(4)
3.4 Objects unify the modeling process	59	(4)
3.5 The use case model captures system requirements	63	(5)
3.6 The analysis model shapes system architecture	68	(6)
3.7 The design model defines the implementation	74	(2)
3.8 The implementation model is the code	76	(1)
3.9 The test model validates the system	77	(1)
3.10 Summary	77	(2)
3.11 Additional reading	79	(1)
4 APPLICATION AND COMPONENT SYSTEMS	80	(34)
4.1 Application developers can reuse OOSE model components	80	(2)
4.2 Application families allow significant reuse	82	(2)
4.3 Application systems are built from reusable components	84	(1)
4.4 Group components into component systems	85	(3)
4.5 Facades control access to component system internals	88	(1)
4.6 Facades and component systems are special kinds of packages	89	(3)
4.7 Component systems export components via facades	92	(2)
4.8 Specialize some components before reuse	94	(3)
4.9 Variability occurs at variation points	97	(2)
4.10 Use several kinds of variability mechanism	99	(6)
4.11 Reuse variable components to build application systems	105	(5)
4.12 Package and document component systems for reuse	110	(3)
4.13 Summary	113	(1)
4.14 Additional reading	113	(1)
5 USE CASE COMPONENTS	114	(19)
5.1 Structure the use case model to ensure component reuse	114	(1)
5.2 The use case model shapes the rest of the system	115	(2)
5.3 Reusing components to build the use case model	117	(1)
5.4 Design the use case components for effective reuse	118	(1)
5.5 Not all use cases should be reusable components	119	(1)
5.6 Reusing concrete or abstract actor and use case components	120	(3)
5.7 Expressing use case variability	123	(6)
5.8 Packaging and documenting use case components	129	(2)
5.9 Summary	131	(1)
5.10 Additional reading	132	(1)
6 OBJECT COMPONENTS	133	(37)
6.1 Object models define system architecture and design	133	(2)
6.2 Reusing analysis and design components	135	(2)
6.3 Expressing variability in object model components	137	(1)
6.4 Tracing use case variability to the object models	138	(8)
6.5 Reusable analysis components	146	(5)
6.6 Subsystem components group related classes	151	(6)
6.7 Reusable design and implementation components	157	(8)
6.8 Packaging and documenting object components and variants	165	(3)
6.9 Summary	168	(1)
6.10 Additional reading	169	(1)
7 LAYERED ARCHITECTURE	170	(43)
7.1 Architecture defines system structure, interfaces, and interaction patterns	171	(1)
7.2 A good architecture is crucial to maintain system integrity	172	(1)
7.3 A layered architecture organizes software according to generality	173	(3)
7.4 A layered architecture reduces software dependencies	176	(1)
7.5 The middleware layer supports distributed object computing	177	(9)
7.6 The business-specific layer supports rapid application development	186	(5)
7.7 Using multiple models when working with layered system architecture	191	(1)
7.8 Representing a layered system as a superordinate system	192	(5)
7.9 Use cases in relation to a layered system	197	(6)
7.10 Actors of the application and component systems	203	(2)
7.11 Use cases for the application and component systems	205	(1)
7.12 Wrapping legacy systems to fit the architecture	206	(2)
7.13 Distributed processes and nodes for a layered system	208	(3)
7.14 Summary	211	(1)
7.15 Additional reading	212	(1)
PART III PROCESSES	213	(124)
8 OBJECT-ORIENTED BUSINESS ENGINEERING	216	(14)
8.1 Business process reengineering achieves dramatic improvements	216	(2)
8.2 A well-defined process for business process reengineering	218	(1)
8.3 Business engineering delivers models as a chart for the future	219	(1)
8.4 Using business actors and use cases to represent value-adding processes	220	(2)
8.5 Using workers and work objects to represent people and results	222	(2)
8.6 Grouping workers into competence units according to skills	224	(2)
8.7 Information systems must support the business use cases and workers	226	(2)
8.8 Summary	228	(1)
8.9 Additional reading	229	(1)
9 APPLYING BUSINESS ENGINEERING TO DEFINE PROCESSES AND ORGANIZATION	230	(28)
9.1 Processes and organization of the Reuse Business match architecture	230	(2)
9.2 Software engineering processes in the Reuse Business	232	(12)
9.3 Organizing workers into competence units	244	(9)
9.4 Interplay between Reuse Business processes	253	(3)
9.5 Summary	256	(1)
9.6 Additional reading	257	(1)
10 APPLICATION FAMILY ENGINEERING	258	(39)
10.1 Developing an architecture for an application family	258	(4)
10.2 Planning the product schedule according to use case priority	262	(4)
10.3 AFE1: Analyzing requirements that have an impact on the architecture	266	(8)
10.4 AFE2: Performing robustness analysis	274	(6)
10.5 AFE3: Designing the layered system	280	(11)
10.6 AFE4: Implementing the architecture as a layered system	291	(1)
10.7 AFE5: Testing the layered system	291	(1)
10.8 Managing architectural change	292	(1)
10.9 Expressing Application Family Engineering in terms of workers	293	(2)
10.10 A leaner approach to Application Family Engineering	295	(1)
10.11 Summary	295	(1)
10.12 Additional reading	296	(1)
11 COMPONENT SYSTEM ENGINEERING	297	(24)
11.1 Building flexible component systems	297	(2)
11.2 CSE1: Analyzing requirements focusing on variability	299	(6)
11.3 CSE2: Performing robustness analysis to maximize flexibility	305	(5)
11.4 CSE3: Designing the component system	310	(2)
11.5 CSE4: Implementing the component system	312	(2)
11.6 CSE5: Testing the component system	314	(1)
11.7 CSE6: Final packaging of the component system for reuse	315	(3)
11.8 Expressing Component System Engineering in terms of workers	318	(1)
11.9 Summary	319	(1)
11.10 Additional reading	320	(1)
12 APPLICATION SYSTEM ENGINEERING	321	(16)
12.1 Building application systems from reusable components	321	(3)
12.2 ASE1: Analyzing requirements	324	(5)
12.3 ASE2: Performing robustness analysis for flexible application systems	329	(1)
12.4 ASE3, ASE4, and ASE5: Designing, implementing, and testing the application system	330	(2)
12.5 ASE6: Packaging the application system for easy installation	332	(1)
12.6 Expressing Application System Engineering in terms of workers	333	(1)
12.7 Summary	334	(1)
12.8 Additional reading	335	(2)
PART IV ORGANIZING A REUSE BUSINESS	337	(84)
13 TRANSITION TO A REUSE BUSINESS	339	(35)
13.1 A systematic, incremental approach is needed	339	(3)
13.2 The incremental transition process	342	(8)
13.3 TRA1: Creating a directive to reengineer the existing software business	350	(4)
13.4 TRA2: Envisioning the new Reuse Business	354	(5)
13.5 TRA3: Reversing the existing software business	359	(2)
13.6 TRA4: Forward engineering the new Reuse Business	361	(6)
13.7 TRA5: Implementing the Reuse Business	367	(4)
13.8 Summary	371	(2)
13.9 Additional reading	373	(1)
14 MANAGING THE REUSE BUSINESS	374	(28)
14.1 Ongoing management is crucial to RSEB success	374	(3)
14.2 Measurement is key to managing the reuse business	377	(7)
14.3 Economic models and reuse investment decisions	384	(11)
14.4 TRA6: Comtinuous process improvement	395	(1)
14.5 Managing people and organization	396	(4)
14.6 Summary	400	(1)
14.7 Additional reading	401	(1)
15 AFTERWORD: MAKING THE REUSE BUSINESS WORK	402	(19)
15.1 Putting it all together	402	(1)
15.2 Reuse improves the performance of your business processes	403	(1)
15.3 Common misconceptions	403	(2)
15.4 Doing reuse is difficult	405	(2)
15.5 Without vision, the people perish	407	(1)
15.6 Reuse depends on architecture	408	(1)
15.7 Management works through organization	409	(1)
15.8 The reuse business must earn a return on its investment	410	(3)
15.9 Software engineering depends on process	413	(1)
15.10 Object technology aids process	414	(1)
15.11 Business engineering: Overhauling the business model	415	(3)
15.12 Summing up	418	(2)
15.13 Additional reading	420	(1)
PART V APPENDICES	421	(60)
A GLOSSARY	423	(18)
B ANNOTATED BIBLIOGRAPHY	441	(13)
B.1 Systematic software reuse	441	(4)
B.2 Object-oriented technology	445	(4)
B.3 Architecture and patterns	449	(2)
B.4 Software engineering	451	(1)
B.5 Business Process Reengineering and Organization Change Management	452	(2)
C USE OF THE UNIFIED MODELING LANGUAGE IN THE RSEB	454	(12)
C.1 Using the Unified Modeling Language	454	(1)
C.2 UML classes and stereotypes	455	(1)
C.3 General RSEB constructs	456	(2)
C.4 The use case model of an information system	458	(1)
C.5 The analysis model of an information system	459	(2)
C.6 The design model of an information system	461	(2)
C.7 The business use case model	463	(1)
C.8 The business object model	464	(2)
D REFERENCES	466	(15)
INDEX	481

Excerpts

This is a book for software engineering practitioners and their managers, interested in dramatically improving their software development performance. For many industrial and commercial enterprises, accomplishing key business goals, such as satisfying the customer, achieving time to market with products and services, or controlling costs, have direct implications on the way they choose to develop and use information technology and software systems for competitive advantage. In most of these cases, objects, component based development and software reuse are key parts of their software engineering strategy. Succeeding with industrial-strength object-oriented software engineering requires that the promise of large-scale software reuse be realized in a practical way. This book provides a pragmatic framework for success. Systematic software reuse Ever since libraries of shared components were first proposed by Doug McIlroy in 1968, software reuse has been recognized as an attractive idea with an obvious payoff. Building software systems from previously developed, high-quality components certainly saves the cost and time of redundant work and improves systems. For many years, obtaining high levels of reuse has been elusive. Many different technical, process, and organizational issues have blocked progress. But despite pursuit after a variety of other "silver bullets" to improve software development, it remains clear that systematic software reuse and component based development is still one of the most promising ways to significantly improve the software development process. Most software development organizations move to object technology because engineering managers believe that this will lead to significant reuse. Unfortunately, without an explicit reuse agenda and a systematic reuse-directed software process, most of these object adoption efforts do not lead to successful large-scale reuse. Why do we use the term "reuse"? No other engineering field uses this term. Instead, the systematic design and use of standard components is accepted practice; many handbooks of hardware components, ranging from motors and gears to chips, are produced annually and studied daily by design engineers. Despite the use of the term "Software-IC" coined by Brad Cox, and component based development as encouraged by Microsoft and others, a software components industry with an associated widespread use of components is still in its infancy. In the future, component-based software engineering will be taught as a standard part of the software engineering curriculum and the word "reuse" will become obsolete; today, we use the term "reuse" to describe the goals of this still emerging area of software engineering. Over the last ten years, the software reuse and software engineering communities have come to better understand component-based software engineering. In almost all cases of successful reuse, the keys were management support, system and component architecture, a dedicated component group, a stable application domain, standards, and organizational support. Many software engineering books and conferences focus specifically on systematic software reuse and on object technology. Many mention of reuse, architecture, and process- and domain-specific application development, but they differ in their approach to reuse. Some object technology books, including Jacobson''s 1992 Object-Oriented Software Engineering (OOSE) book, address certain object reuse issues directly or have significant sections on reuse. Appendix B provides an annotated bibliography of pertinent work. What is this book about? This book is directed at bringing us significantly closer to a future in which object-oriented component-based software engineering will become the norm. There is a growing belief that systematic, large-scale reuse, coupled with object technology, is the only way to radically improve the process of software development. Based on our experience with reuse at Hewlett-Packard and Objectory (now Rational), and with our many customers, we believe that substantial degrees of reuse can be achieved only by radically changing traditional software architectures and development processes. First, we are convinced that substantial reuse requires that software must be architected, designed, packaged, and supported for reuse. Architecture here means that systems and components must be structured to support independent development, and later integration and evolution, of components and systems. Second, the software engineering processes, involving specific software development steps, the supporting management and organizational structures, and even the mode of interaction with customers, must be adapted to allow the organization to work effectively with these reusable components. Finally, processes and tools must be integrated into an infrastructure to support the key activities. Introducing effective reuse into a software engineering business requires a concerted and systematic effort by both management and software developers in order to overcome the business, process, organizational, and technical impediments that often hinder effective reuse. Effort must also be directed at involving customers, users and maintainers early on. While many of these issues and possible solutions are by now well-known in the reuse community, their existence still comes as a surprise to those who adopt object technology and expect it to yield reuse automatically. Without an explicit reuse agenda and a systematic approach to design and process, the desired levels of object reuse will not be achieved. In this book we develop a coherent model and a set of guidelines that help ensure success with large- scale, object-oriented reuse. Our framework, which we call the Reuse-Driven Software Engineering Business (abbreviated as Reuse Business), deals systematically with these key business, process, architecture, and organization issues. We believe that both the theory and practice of systematic software reuse and the theory and practice of systematic, model-based, object-oriented software development and business engineering have matured sufficiently for us to develop this new, consistent approach. Our coherent solution merges the best ideas of both fields with our own contributions in the areas of systematic methods, architectures, domain-specific software engineering, and reuse adoption. Who needs a Reuse-Driven Software Engineering Business? Any software-producing organization can benefit from the ideas presented in this book. After many years of cautiously viewing object technology as interesting but still emerging, many large organizations have increased their commitment to objects and are investing substantial resources in re-engineering their businesses and reimplementing their supporting information systems. For many businesses, an effective software engineering development strategy is an essential part of their use of information technology to accomplish key business objectives, such as effective use of resources, improved time-to-market, and agile response to market change. They are looking to objects and reuse to provide them flexible, cost-effective implementations, which are based on commercial and their own application frameworks, reusable business components and distributed object-oriented middleware. To help them achieve their strategic software goals, we provide a clear statement of how large-scale, architected object reuse can help improve the software process. Our reuse business model describes how these software organizations can transition to a reuse-driven business. The full benefits will only be obtained if the software organization: Produces related applications (or significant sub-systems) that are members of a product line or product family; Is willing to make a significant investment t