Content URL: Link To Content
Software is rarely built completely from scratch. To a great extent, existing software documents (source code, design documents, etc.) are copied and adapted to fit new requirements. Yet we are far from the goal of making reuse the standard approach to software development.
Software reuse is the process of creating software systems from existing software rather than building them from scratch. Software reuse is still an emerging discipline. It appears in many difierent forms from ad-hoc reuse to systematic reuse, and from white-box reuse to black-box reuse. Many difierent products for reuse range from ideas and algorithms to any documents that are created during the software life cycle. Source code is most commonly reused; thus many people misconceive software reuse as the reuse of source code alone. Recently source code and design reuse have become popular with (object-oriented) class libraries, application frameworks, and design patterns. Software components provide a vehicle for planned and systematic reuse. The software community does not yet agree on what a software component is exactly. Nowadays, the term component is used as a synonym for object most of the time, but it also stands for module or function. Recently the term component-based or component-oriented software development has become popular. In this context components are defined as objects plus something. What something is exactly, or has to be for effective software development, remains yet to be seen. However, systems and models are emerging to support that notion.
Systematic software reuse and the reuse of components influence almost the whole software engineering process (independent of what a component is). Software process models were developed to provide guidance in the creation of high-quality software systems by teams at predictable costs. The original models were based on the (mis)conception that systems are built from scratch according to stable requirements. Software process models have been adapted since based on experience, and several changes and improvements have been suggested since the classic waterfall model. With increasing reuse of software, new models for software engineering are emerging. New models are based on systematic reuse of well-defined components that have been developed in various projects.
Developing software with reuse requires planning for reuse, developing for reuse and with reuse, and providing documentation for reuse. The priority of documentation in software projects has traditionally been low. However, proper documentation is a necessity for the systematic reuse of components. If we continue to neglect documentation we will not be able to increase productivity through the reuse of components. Detailed information about components is indispensable.
The book Software Engineering with Reusable Components is divided into four main parts. They cover the topics software reuse, software components, software engineering and software documentation. These four parts are complemented by an introductory and a concluding chapter. The introductory chapter introduces the notions of software reuse and software component. The concluding chapter summarizes the subject matter and provides concluding remarks on the limits of component reuse and its prospects. In the following synopsis we briefly sketch the contents of the four main parts.
Part I: Software Reuse
Even though software reuse has been practiced in one form or another over many years, it is still an emerging discipline. In the first part of the book we give a comprehensive overview of the subject, describing benefits and obstacles to software reuse as well as various aspects like reuse techniques and reuse products. Nontechnical aspects like legal, economic, measurement and organizational issues are covered as well. The main focus of the book is on technical aspects of software reuse, especially reuse of software components. However, this part also contains information about other forms of reuse and distinguishes them.
This part of the book provides the reader with a clear understanding of what software reuse is, where the problems are, what benefits we can expect, the activities it encompasses, and which difierent forms of software reuse exist.
Part II: Software Components
In the second part of the book we give an extensive introduction to software components. We provide a classification of components and composition techniques. This classification goes beyond source code components and also covers aspects from the area of distributed computing and emphasizes the importance of open systems and standards. There is more to software components than functions and classes. Like software reuse, software components go beyond source code. Components cover a broader range than frameworks and patterns do. We give examples of successful component reuse and evaluate them by using the suggested classification scheme.
This part of the book gives the reader an overview of software components, the difierent kinds of components and their compositions, a taxonomy for components and compositions, and examples of successful component reuse.
Part III: Software Engineering
Software engineering covers activities that are necessary to develop a software system. The reuse of software components has consequences for the way we develop systems. Software life cycles have been influenced by many new developments that resulted in modified models like the risk-based spiral model. Software reuse introduces new activities, like domain analysis, and changes existing ones, e.g., design activities. Developing with reuse and developing for reuse are the new challenges as compared to developing systems from scratch to meet certain requirements.
This part of the book gives the reader an introduction to software en- gineering and software process models. Chapters on domain engineering, component engineering and application engineering depict consequences of and influences from the systematic reuse of software components.
Part IV: Software Documentation
Software documentation fulfills the vital function of retaining and transferring knowledge about various aspects of software systems. We cover the part of the documentation that is affected by the reuse of software components, i.e., system documentation. On the one hand, system documentation has to consider the information needs of software reusers. On the other hand, the reuse of software components suggests the reuse of documentation as well.
This part of the book gives the reader an introduction to software documentation in general and details consequences for system documentation that result from the reuse of software components.
The book Software Engineering with Reusable Components is intended for readers at universities as well as in industry. Any readers who are interested in software reuse in general and in component reuse and component-oriented software engineering in particular will find useful information in this book. Readers can expect to gain a comprehensive overview of software reuse and software components and their influences on software engineering and software documentation.
Software is rarely built completely from scratch. To a great extent, existing software documents (source code, design documents, etc.) are copied and adapted to fit new requirements. Yet we are far from the goal of making reuse the standard approach to software development.
Software reuse is the process of creating software systems from existing software rather than building them from scratch. Software reuse is still an emerging discipline. It appears in many difierent forms from ad-hoc reuse to systematic reuse, and from white-box reuse to black-box reuse. Many difierent products for reuse range from ideas and algorithms to any documents that are created during the software life cycle. Source code is most commonly reused; thus many people misconceive software reuse as the reuse of source code alone. Recently source code and design reuse have become popular with (object-oriented) class libraries, application frameworks, and design patterns. Software components provide a vehicle for planned and systematic reuse. The software community does not yet agree on what a software component is exactly. Nowadays, the term component is used as a synonym for object most of the time, but it also stands for module or function. Recently the term component-based or component-oriented software development has become popular. In this context components are defined as objects plus something. What something is exactly, or has to be for effective software development, remains yet to be seen. However, systems and models are emerging to support that notion.
Systematic software reuse and the reuse of components influence almost the whole software engineering process (independent of what a component is). Software process models were developed to provide guidance in the creation of high-quality software systems by teams at predictable costs. The original models were based on the (mis)conception that systems are built from scratch according to stable requirements. Software process models have been adapted since based on experience, and several changes and improvements have been suggested since the classic waterfall model. With increasing reuse of software, new models for software engineering are emerging. New models are based on systematic reuse of well-defined components that have been developed in various projects.
Developing software with reuse requires planning for reuse, developing for reuse and with reuse, and providing documentation for reuse. The priority of documentation in software projects has traditionally been low. However, proper documentation is a necessity for the systematic reuse of components. If we continue to neglect documentation we will not be able to increase productivity through the reuse of components. Detailed information about components is indispensable.
The book Software Engineering with Reusable Components is divided into four main parts. They cover the topics software reuse, software components, software engineering and software documentation. These four parts are complemented by an introductory and a concluding chapter. The introductory chapter introduces the notions of software reuse and software component. The concluding chapter summarizes the subject matter and provides concluding remarks on the limits of component reuse and its prospects. In the following synopsis we briefly sketch the contents of the four main parts.
Part I: Software Reuse
Even though software reuse has been practiced in one form or another over many years, it is still an emerging discipline. In the first part of the book we give a comprehensive overview of the subject, describing benefits and obstacles to software reuse as well as various aspects like reuse techniques and reuse products. Nontechnical aspects like legal, economic, measurement and organizational issues are covered as well. The main focus of the book is on technical aspects of software reuse, especially reuse of software components. However, this part also contains information about other forms of reuse and distinguishes them.
This part of the book provides the reader with a clear understanding of what software reuse is, where the problems are, what benefits we can expect, the activities it encompasses, and which difierent forms of software reuse exist.
Part II: Software Components
In the second part of the book we give an extensive introduction to software components. We provide a classification of components and composition techniques. This classification goes beyond source code components and also covers aspects from the area of distributed computing and emphasizes the importance of open systems and standards. There is more to software components than functions and classes. Like software reuse, software components go beyond source code. Components cover a broader range than frameworks and patterns do. We give examples of successful component reuse and evaluate them by using the suggested classification scheme.
This part of the book gives the reader an overview of software components, the difierent kinds of components and their compositions, a taxonomy for components and compositions, and examples of successful component reuse.
Part III: Software Engineering
Software engineering covers activities that are necessary to develop a software system. The reuse of software components has consequences for the way we develop systems. Software life cycles have been influenced by many new developments that resulted in modified models like the risk-based spiral model. Software reuse introduces new activities, like domain analysis, and changes existing ones, e.g., design activities. Developing with reuse and developing for reuse are the new challenges as compared to developing systems from scratch to meet certain requirements.
This part of the book gives the reader an introduction to software en- gineering and software process models. Chapters on domain engineering, component engineering and application engineering depict consequences of and influences from the systematic reuse of software components.
Part IV: Software Documentation
Software documentation fulfills the vital function of retaining and transferring knowledge about various aspects of software systems. We cover the part of the documentation that is affected by the reuse of software components, i.e., system documentation. On the one hand, system documentation has to consider the information needs of software reusers. On the other hand, the reuse of software components suggests the reuse of documentation as well.
This part of the book gives the reader an introduction to software documentation in general and details consequences for system documentation that result from the reuse of software components.
The book Software Engineering with Reusable Components is intended for readers at universities as well as in industry. Any readers who are interested in software reuse in general and in component reuse and component-oriented software engineering in particular will find useful information in this book. Readers can expect to gain a comprehensive overview of software reuse and software components and their influences on software engineering and software documentation.
