Home > Store

Software Reuse: Architecture, Process and Organization for Business Success

Register your product to gain access to bonus material or receive a coupon.

Software Reuse: Architecture, Process and Organization for Business Success

Book

  • This product currently is not for sale.
Not for Sale

Description

  • Copyright 1997
  • Dimensions: 6-1/2x9-1/16
  • Pages: 528
  • Edition: 1st
  • Book
  • ISBN-10: 0-201-92476-5
  • ISBN-13: 978-0-201-92476-3

"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

Downloads

Supplements

Click below for Supplements related to this title:
Supplements

Sample Content

Table of Contents

Preface
Systematic software reuse
What is this book about?
Who needs a Reuse-Driven Software Engineering Business?
The essence of the Reuse-Driven Software Engineering Business
Our experience
How this book is organized
What this book offers
Acknowledgments
Dedications

PART I - INTRODUCING THE REUSE-DRIVEN SOFTWARE ENGINEERING BUSINESS
1. Software Reuse Success Factors
1.1 Software reuse is a simple idea
1.2 Components are fueling a revolution in application development
1.3 A systematic approach makes pragmatic reuse work
1.4 Ericsson and Hewlett-Packard reuse experience reveals common principles
1.5 Reuse requires changes in process
1.6 Reuse requires changes in organization
1.7 Adopt reuse systematically and incrementally
1.8 Input from other reuse programs
1.9 It takes a set of principles
1.10 Summary

2. Reuse-Driven Software Engineering Is A Business
2.1 Is it a business for you?
2.2 Make reuse cost-effective
2.3 A Reuse Business has business characteristics
2.3 Architect components and applications
2.4 Software engineering processes
2.5 Establishing and managing a reuse business
2.6 Summary

PART II - ARCHITECTURAL STYLE
3. Object-Oriented Software Engineering
3.1 Software engineering transforms requirements into code
3.2 Software engineering is a team process
3.3 Software engineering is systematic model building
3.4 Objects unify the modeling process
3.5 The use case model captures system requirements
3.6 The analysis model shapes system architecture
3.7 The design model defines the implementation
3.8 The implementation model is the code
3.9 The test model validates the system
3.10 Summary

4. Application And Component Systems
4.1 Application developers can reuse OOSE model components
4.2 Application families allow significant reuse
4.3 Application systems are built from reusable components
4.4 Group components into component systems
4.5 Facades control access to component system internals
4.6 Facades and component systems are special kinds of packages
4.7 Component systems export components via facades
4.8 Specialize some components before reuse
4.9 Variability occurs at variation points
4.10 Use several kinds of variability mechanisms
4.11 Reuse variable components to build application systems
4.12 Package and document component systems for reuse
4.13 Summary

5. Use Case Components
5.1 Structure the use case model to ensure component reuse
5.2 The use case model shapes the rest of the system
5.3 Reusing components to build the use case model
5.4 Design the use case components for effective reuse
5.5 Not all use cases should be reusable components
5.6 Reusing concrete or abstract actor and use case components
5.7 Expressing use case variability
5.8 Packaging and documenting use case components
5.9 Summary

6. Object Components
6.1 Object models define system architecture and design
6.2 Reusing analysis and design components
6.3 Expressing variability in object model components
6.4 Tracing use case variability to the object models
6.5 Reusable analysis components
6.6 Subsystem components group related classes
6.7 Reusable design and implementation components
6.8 Packaging and documenting object components and variants
6.9 Summary

7. Layered Architecture
7.1 Architecture defines system structure, interfaces and interaction patterns
7.2 A good architecture is crucial to maintain system integrity
7.3 A layered architecture organizes software according to generality
7.4 A layered architecture reduces software dependencies
7.5 The middleware layer supports distributed object computing
7.6 The business-specific layer supports rapid application development
7.7 Using multiple models when working with layered system architecture
7.8 Representing a layered system as a superordinate system
7.9 Use cases in relation to a layered system
7.10 Actors to the application and component systems
7.11 Use cases for the application and component systems
7.12 Wrapping legacy systems to fit the architecture
7.13 Distributed processes and nodes for a layered system
7.14 Summary

PART III - PROCESSES
8. Object-Oriented Business Engineering
8.1 Business process reengineering achieves dramatic improvement
8.2 A well-defined process for business process reengineering
8.3 Business engineering delivers models as a chart for the future
8.4 Using business actors and use cases to represent value-adding processes
8.5 Using workers and work objects to represent people and results
8.6 Grouping workers into competence units according to skills
8.7 Information systems must support the business use cases and workers
8.8 Summary

9. Applying Business Engineering to the Reuse Business - to define Processes and Organization
9.1 Processes and organization of the Reuse Business match architecture
9.2 Software engineering processes in the Reuse Business
9.3 Organizing workers into competence units
9.4 Interplay between Reuse Business processes
9.5 Summary

10. Application Family Engineering
10.1 Developing an architecture for an application family
10.2 Planning product schedule based on use case priority
10.3 AFE1: Analysing requirements that have impact on the architecture
10.4 AFE2: Performing robustness analysis
10.5 AFE3: Designing the layered system
10.6 AFE4: Implementing the architecture as a layered system
10.7 AFE5: Testing the layered system
10.8 Managing architectural change
10.9 Expressing application family engineering in terms of workers
10.10 A leaner approach to application family engineering
10.11 Summary

11. Component System Engineering
11.1 Building flexible component systems
11.2 CSE1: Analyzing requirements focusing on variability
11.3 CSE2: Performing robustness analysis to maximize flexibility
11.4 CSE3: Designing the component system
11.5 CSE4: Implementing the component system
11.6 CSE5: Testing the component system
11.7 CSE6: Final packaging the component system for reuse
11.8 Expressing Component System Engineering in terms of workers
11.9 Summary

12. Application System Engineering
12.1 Building application systems from reusable components
12.2 ASE1: Analyzing requirements
12.3 ASE2: Performing robustness analysis for flexible application systems
12.4 ASE3, ASE4 and ASE5: Designing, implementing and testing the application system
12.5 ASE6: Packaging the application system for easy installation
12.6 Expressing Application System Engineering in terms of workers
12.7 Summary

PART IV - ORGANIZING A REUSE BUSINESS
13. Transition To A Reuse Business
13.1 A systematic, incremental transition controls risk
13.2 The incremental transition process
13.3 TRA1: Creating a directive to reengineer the existing software business
13.4 TRA2: Envisioning the new Reuse Business
13.5 TRA3: Reversing the existing software business
13.6 TRA4: Forward engineering the new Reuse Business
13.7 TRA5: Implementing the Reuse Business
13.8 Summary

14. Managing The Reuse Business
14.1 Ongoing management is crucial to RSEB success
14.2 Measurement is key to managing the reuse business
14.2
14.3 Economic models and reuse investment decisions
14.4 TRA6: Continuous process improvement
14.5 Managing people and organization
14.6 Summary

15. Afterword: Making The Reuse Business Work
15.1 Putting it all together
15.2 Reuse improves the performance of your business processes
15.2
15.3 Common misconceptions
15.4 Doing reuse is difficult
15.5 Without vision, the people perish
15.6 Reuse depends on architecture
15.6
15.7 Management works through organization
15.7
15.8 The reuse business must earn a return on its investment
15.8
15.9 Software engineering depends on process
15.10 Object technology aids process
15.10
15.11 Business engineering: overhauling the business model
15.12 Summing up

PART V - APPENDICES
A. Glossary
B. Annotated Bibliography
B.1 Systematic Software Reuse
B.2 Object technology
B.3 Architecture and patterns
B.4 Software engineering
B.5 Business Process Reengineering and Organizational Change Managment
C. Use of the Unified Modeling Language in the RSEB
C.1 The Use of the Unified Modeling Language
C.2 UML classes and stereotypes
C.3 General constructs
C.4 The Use Case Model of an information system
C.5 Analysis Model of an information system
C.6 Design Model of an information system
C.7 Business use case model
C.8 Business object model
D. References

INDEX

Preface

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 to build up reusable architectures, components, processes, and tools; and
  • Is willing to make certain process and organizational changes.

Such an organization is usually feeling increasing pressure to deliver more applications in shorter times, in order to meet more complex customer needs.

The essence of the Reuse-Driven Software Engineering Business

In our discussion, we distinguish the term "the Reuse Business," referring to our generic model or framework, from the term "a reuse business," referring to a particular software organization that is a specialized instance of the Reuse Business. We have targeted our approach to yield significant results for organizations in which the development of mission critical information systems and software products are key to their success. We also address how the Reuse Business may be specialized to a range of organizations that are able to benefit from many aspects of our systematic approach to reuse, even if they are not able or do not choose to operate fully in accord with our model.

In the optimal case, the software development organization is run as a software engineering business. By business, we mean both that the information technology and software engineering goals are key to accomplishing the enterprise business goals, and that as a consequence, the software organization itself is operated as a business, with well defined customer and financial objectives. As a reuse-driven software organization, this organization is engaged in producing multiple, related applications, centered and optimized on the production and reuse of components. These applications commonly form a product-line or product family. As a business, this organization must understand its customers, and serve their needs, while at the same time effectively achieving its profit and expense objectives. Such business tradeoffs are managed using economic, product and process measures.

The Reuse Business involves incremental, architecture-centric, process-driven, domain-specific software development. It also links previously independent projects, introduces new architectures, changes the development processes, requires reusable component management and funding activities, and changes the roles of architects, process engineers, development engineers, and managers. Thus significant organizational change is involved.

The Reuse Business model integrates essential ideas and pragmatic guidelines from our knowledge of systematic reuse and from our experience with the architecture and the development processes used to develop the AXE Telecom switching system at Ericsson, and with reuse architecture, process, adoption, and organization experience gained with Hewlett-Packard's Corporate Reuse Program.

We base our work on Jacobson's use case driven architecture and process modeling frameworks U Object-Oriented System Engineering (OOSE)Jacobson92 and Object-Oriented Business Engineering, described in "The Object Advantage"(TOA)Jacobson94. By so doing, we integrate the key aspects of many successful, but fragmentary approaches to reuse process, frameworks, reuse organization, domain engineering, and domain-specific kits into a coherent model. With this approach, we can relate and optimize all processes (activities and supporting infrastructure) and products (architecture and components) to the business goals of a reuse business.

The Reuse Business extends OOSE to provide support for architecting reuse-oriented applications and components. New constructs support layered, modular architectures, in which application systems are built from flexible, reusable components. Related components are grouped into component systems.

The Reuse Business model applies business engineering to the software engineering organization itself. The Object-Oriented Business Engineering framework Jacobson94 provides a consistent, systematic approach to the organizational and process issues. Business use cases model the key software development processes, component engineering and application engineering. Business use cases model the interaction of persons with the software organization. These models then define the roles of reuse workers, to produce a reuse-oriented software organization structure that meets the needs of specific software development organizations. A business reengineering transition framework and change management techniques are used to systematically restructure a software development organization into a reuse business.

Our experience

Since mid-1993, when the authors of this book first became familiar with each other's work, we have worked closely together on panels, at conferences, at workshops, and in joint research in order to integrate our skills and experiences into the shared vision described in this book. Together, we are uniquely positioned with a wealth of complementary skills. Ivar Jacobson brings the strong architectural perspective and large systems experience of developing the AXE Telecom switching system at Ericsson, and the experience gained with Objectory development and clients. Martin Griss has broad experience with reuse organization, adoption, and technology. Both have extensive experience with systematic software process definition and improvement. Patrik Jonsson joined the work in May 1994, bringing his Objectory process experience to the project, when we decided to make our efforts into a formal collaboration leading to this book.

Ivar Jacobson is inventor of the OOSE method and founder of Objectory AB, Sweden. He is currently VP of Business Engineering at Rational Software Corporation, and was before that VP of Technology at Objectory Corporation. He is a leader in the object-oriented community. He is well-known for his pioneering work and more than 20 years of experience using object methods for the design of large real-time systems. He spent 25 years at Ericsson working on the AXE switching system, where he developed an architecture and software engineering process to support extensive reuse. His early object-based design technique has evolved into the international CCITT/SDL Telecom standard. He is the principal author of two influential books: "Object-Oriented Software Engineering - A Use Case Driven Approach" and "The Object Advantage - Business Process Reengineering with Object Technology," as well as several widely referenced papers on object technology. His work on use case engineering has influenced almost all of the OO methods in use today. He has served on the OOPSLA, ECOOP, and TOOLS program committees.

Martin L. Griss is a senior Laboratory Scientist at Hewlett-Packard Laboratories, Palo Alto, California where for the last 14 years he has researched software engineering processes and systems, systematic software reuse, object-oriented reuse, and measurement system kits. He has a defining role as senior reuse consultant within HP's Professional Services Organization, working with the Object-Oriented Solutions Center. As HP's "reuse rabbi," he led research on software reuse process, tools, and software factories; the creation of an HP Corporate Reuse program; and the systematic introduction of software reuse into HP's divisions. He was director of the Software Technology Laboratory at Hewlett-Packard Laboratories, and has over 25 years of experience in software engineering research. He was previously an associate professor of computer science at the University of Utah, where he is currently an adjunct professor. He has authored numerous papers and reports on software engineering and reuse, writes a reuse column for Object Magazine, and is active on several reuse program committees.

Patrik Jonsson was one of the first people to join Objectory AB, and has been working closely with Ivar for many years. He has been involved in several different activities, including customer projects, process and method development, specifying the requirements for the Objectory CASE tool, and teaching. He is a co-author of the Addison-Wesley bestseller Object-Oriented Software Engineering - A Use Case Driven Approach. He now works at Rational as a member of the process development group. Patrik joined Ivar and Martin to help capture and formulate their ideas. He has been a main driver in integrating the concept of a Reuse-Driven Software-Engineering Business into the software engineering framework of Objectory, and has added many ideas of his own.

How this book is organized

The book consists of four parts:

Part I: Introducing the Reuse-Driven Software-Engineering Business, provides motivation, background and an overview of our systematic reuse-driven approach, abbreviated the Reuse Business. Chapter 1 surveys software reuse experiences and key management, architecture, process and organizational principles, that motivate the approach we have taken. Chapter 2 describes the overall concepts and goals of the Reuse Business. We define application systems and component systems, and describe the key processes of application systems engineering, which utilizes component systems to build applications and component systems engineering, which creates reusable component systems.

Part II: Architectural Style, describes the architectural concepts and notation that underlie the Reuse Business. These architectural building blocks, connectors, and composition rules enable us to describe a variety of architectures. Chapter 3 introduces Object-Oriented Software Engineering (OOSE) and the Unified Modeling Language, including models, actors, use cases, objects, and systems. Chapter 4 describes application systems, components and component systems. We define the concept of facade as a generalized interface, and describe variability mechanisms that provide manageable, yet flexible reuse. Chapters 5 and 6 provide much more detail on use case and object components. Chapter 7 addresses layered architectures and systems of interconnected systems to support large-scale, controlled reuse.

Part III: Reuse Business Processes, addresses the reuse-oriented software engineering processes needed to systematically create, use, and manage the architectural elements described in Part II. Chapter 8 describes Object-Oriented Business Engineering, including the modeling of business systems, business processes, and workers. Business models are connected to information systems and human resources. Business Engineering and OOSE can be used together to develop and precisely describe the processes, organization models, and tools underlying the Reuse Business. Chapter 9 describes a high-level business model for the Reuse Business, which provides a framework for the more detailed treatment of the key processes and organizations in the following chapters. We define and relate component systems engineering, application systems engineering, application family engineering and managing reuse. Chapter 10 applies business engineering to the customer business to define the suite of applications that supports their business processes. Analysis of these applications then leads to the overall layered architecture and decomposition into reusable component systems. The incorporation of legacy systems is also addressed. Chapter 11 describes component systems engineering, showing how to analyze sets of requirements to produce high-quality components and their facades. Chapter 12 describes application systems engineering, showing how to construct applications by selecting, customizing, and reusing components drawn from one or more component systems.

Part IV: Organizing A Reuse Business, provides advice on establishing a specific reuse business that conforms to the Reuse Business model. Chapter 13 describes a systematic transition to a reuse business, combining business engineering techniques with change management and reuse-specific guidelines. This leads to an incremental adoption process, with several process and organization changes. The basic Reuse Business model can be adapted to a variety of software development scenarios. Business engineering techniques are used to partition the reuse roles and departments to create organizational structures for a specific reuse business. Several tools and technologies help manage the process, and create and package the component systems. Chapter 14 describes how instances of the various processes are created and managed, what techniques and economic, process, and product measures are used to manage tradeoffs and progress flow, and what organizational and technical infrastructure is needed to support a reuse business. Chapter 15 provides a summary of the key architectural, process and organizational principles, and suggests directions for your next steps.

The appendixes provide detailed reference material. Appendix A is a complete glossary of terms. Appendix B is an annotated bibliography of key readings and on-line resources, while appendix C lists all references used in the book.

What this book offers

This book on industrial object-oriented software engineering with substantial reuse has as its main purpose the explanation of the key issues involved in building a Reuse-Driven Software Engineering Business. The reader does not need any object or reuse experience in order to understand the book.

This book is not a complete handbook and therefore does not provide all the detailed information necessary to implement and run a reuse business. More detailed process guides, training and practical experience will be needed to ensure success. Just as OOSE and Object Oriented Business Engineering are simplifications of the more detailed and precise Rational Objectoryä SE and BE processes, the work presented in this book is the simplification of a more complex process.

It is important that all readers, potential participants in the Reuse Business, have a shared understanding of the key concepts, as covered in Chapters 1 and 2, and the introductions to each Part. People who are:

  • Upper managers, responsible for authorizing and funding the move to a reuse business, should also read chapters 13 and 14 carefully.
  • Reuse managers responsible for the day-to-day running of a reuse business should read all chapters.
  • Project managers should be read chapters 3, 4 and 7 in Part II and the processes described in Part III.
  • Software engineers, system architects, component developers, reusers and component system maintainers, should be familiar with all of Part II, Architectural Style, and the particular processes described in Part III that are most relevant to their role.

These readers might expect to gain the following:

  • Upper Managers want to understand the economic, political and organizational consequences as well as the time-to-market, quality and cost benefits.
  • Reuse Managers want to establish, run and improve a large-scale reuse organization.
  • Project Managers want to learn how to run application projects, and what process changes are needed to take advantage of reuse.
  • System Architects want to design an architecture that allows for substantial reuse and evolution.
  • Component Developers want to learn how to design and build reusable component systems.
  • Reusers want to learn how to build applications from component systems.
  • Maintainers of component systems want to package and support component systems, and to deliver associated services.

While we have designed the book for managers and practitioners who have not much practical experience with object-oriented software or systematic software reuse, the reader who has experience in one or both of these areas should still find considerable material of value. In particular:

  • If the reader is already familiar with the concepts of systematic software reuse, such as domain engineering and creator/utilizer reuse-oriented process and organization, he will see how we have integrated these concepts into a significant object-oriented method, OOSE, software architecture, and how we have taken advantage of object-oriented business engineering.

  • If the reader already has experience with an object-oriented analysis and design method, he will see how we have adapted and extended the architecture and process of OOSE to incorporate an agenda of large-scale, systematic reuse.

  • If the reader already knows OOSE or Rational ObjectoryU, he will see how it has been extended to take advantage of the new Unified Modeling Language (UML), software architecture, and reuse process and technology.

When we started this work, we imagined that we would simply combine what we each knew about object-oriented software engineering, business engineering and systematic software reuse, based on our many years of experience. But as the work progressed, we discovered that we needed to make numerous technical innovations, synthesizing, extending and inventing many ideas. Some of these included:

  • Re-expressing OOSE using the Unified Modeling Language (UML). As we did this, several of our architectural, process and reuse extensions provided useful input to the evolving UML design.
  • Extending and exploiting OOSE and Object-Oriented Business Engineering in order to support the key technical, process and incremental adoption aspects of systematic software reuse. New constructs for components, facades, layered architectures and variability were devised.
  • Discovering how to use and extend OOSE and Object-oriented Business Engineering to do a systematic form of reuse domain-engineering and architecture development.
  • Discovering how the business processes, the software engineering processes and the organization needed to change to optimize the development of enterprise information systems based on substantial reuse.

Acknowledgments

Many people provided inspiration and encouragement that led to the creation of this book. Some helped by commenting on the form and content of the book, others by participating in tutorials and providing feedback, and others by open discussion of the ideas.

We particularly thank Ramesh Balasubramanian, Per Björk, Stefan Bylund, Patricia Cornwell, Nathan Dykman, Håkan Dyrhage, Christian Ehrenborg, John Favaro, Daryl Foy, Steven Fraser, Agneta Jacobson, Phillipe Kruchten, Reed Letsinger, Mary Loomis, Ruth Malan, Patricia Markee, Vered Marash, Susan McBain, Ware Myers, Keith Moore, Karin Palmqvist, Joe Podolsky, Jeff Poulin, Mats Rahm, David Redmond-Pyle, Mark Simos, Mike Short, Greg Siu, Kevin Wentzel and Lorna Zorman for their detailed comments, and commitment.

We particularly appreciate the efforts of Ware Myers who helped us rewrite several chapters of this book to make them more effective, and to Lorna Zorman who carefully read and suggested improvements to many drafts of many chapters. We are highly indebted to Karin Palmqvist, Susanne Dyrhage and Staffan Ehnebom, who participated in the development of the concept of System of Interconnected Systems. We are grateful to Stefan Bylund, Christian Ehrenborg, Magnus Christerson, Staffan Ehnebom, Gunnar Övergaard, for their participation in the development of the notion of interfaces, processes and physical devices as they appear in this book. We are grateful to Gunnar Magnusson and Håkan Dyrhage for their helpful suggestions and comments on applying Object-Oriented Business Engineering to a software development organization. Patricia Cornwell was a key partner in the development of Hewlett-Packard's reuse maturity model and incremental transition strategy that significantly influenced our treatment in chapter 13.

We are grateful to Hewlett-Packard, Objectory and Rational for supporting this project, and to Mary Loomis for providing encouragement and support that enabled us to start and complete this work. Finally, we thank our family members and partners for their patience during the many, many, many weekends and evenings that we worked on the book.

Dedications

Martin Griss - "To the memory of my father, Isaac Griss, who would have been so proud. To P'nina,

Doron and Shelli, for their encouragement, support and understanding."

Patrik Jonsson - "To my beloved wife Katarina, and my two wonderful sons Gabriel and Samuel."

Ivar Jacobson
Stockholm, Sweden
ivar@rational.com

Martin Griss
Palo Alto, California
griss@hpl.hp.com

Patrik Jonsson
Stockholm, Sweden
patrik@rational.com



0201924765P04062001

Updates

Submit Errata

More Information

Unlimited one-month access with your purchase
Free Safari Membership