Component-Based Systems

Estimating Efforts Using Soft Computing Techniques

Kirti Seth, Ashish Seth, Aprna Tripathi

• Publisher: CRC Press
• Year: 2020
• Print ISBN: 9780367856090
• eBook ISBN: 9781000209280
• Edition: 1
• Topic: Computer Science
• Subtopic: Computer Science General
• Index: Computer Science

Businesses today are faced with a highly competitive market and fast-changing technologies. In order to meet demanding customers' needs, they rely on high quality software. A new field of study, soft computing techniques, is needed to estimate the efforts invested in component-based software.

Component-Based Systems: Estimating Efforts Using Soft Computing Techniques is an important resource that uses computer-based models for estimating efforts of software. It provides an overview of component-based software engineering, while addressing uncertainty involved in effort estimation and expert opinions. This book will also instruct the reader how to develop mathematical models.

This book is an excellent source of information for students and researchers to learn soft computing models, their applications in software management, and will help software developers, managers, and those in the industry to apply soft computing techniques to estimate efforts.

1 An Introduction to Component-Based Software Systems

Improving business performance often requires improvement in the execution of product advancement, and this is the motivation that brings engineers and analysts closer to thinking about adopting the latest innovations and improvements. Previous systems evolved with the use of structured methodology, which was successful albeit only for straightforward applications. The Object Oriented (OO) approach came at that stage, which is based on encapsulation, inheritance, and polymorphism. Encapsulation combines the attributes and actions regulating the information in a single article. Inheritance engages a class, ascribes, and duties to be taken up by all subclasses and the items that they start from. Polymorphism allows different activities to have a similar name, reducing the estimation of the lines of code required to conduct a system. In the early 1990s, object-oriented programming became the main component of decisions made by some product manufacturers, a number of data frameworks, and experts in building. In spite of this, the core behavior of software engineers is still unchanged except for a few OO approach preferences: composing line-by-line code. In case of difficulties, it is not easy to implement object-bearing to complex applications. In addition, OO dialects reinforce class-level coverage of results, but not beyond that. Certain fundamental issues in the OO approach are integrity and privacy.

1.1 Component-Based Development

This is an approach that recognizes the fact that many data-based systems include similar or even indistinguishable items that are generated over and over without any planning. Progress is increasingly costly from the start and can require a lot of effort to finish. Because of postponements in the improvement process, simple applications with severe time constraints can liberate the market. This has facilitated the development of another approach, called component-based development (CBD), which uses the reusability concept to improve the application. The use of regular components enables higher profitability. The two core values which accompany CBD can be best depicted as:

1. (1) Re-use but do not reinvent.
2. (2) Instead of coding line-by-line, assemble pre-built components.

Here, sections are seen as groups of schedules that are developed based on well-characterized criteria, with the aim that these families work together as blocks of construction.

1.1.1 Component

Component-based software development (CBSD) is a technique in which software is worked by combining the components with individual parts from freely accessible items. A few proposals emphasize that components are handily informed packets about useful behavior, while others ensure that components are real, deployable programming units that are implemented within a system.

A few concepts for the components have been suggested by researchers. The majority of those are discussed in Table 1.1.

TABLE 1.1
Different Definitions of Components

Researcher	Definition
Sparling, 2000	A component is a non-partisan language, freely executed bundle of software services, transmitted in an embodied and replaceable compartment, obtained through at least one distributed interface. While a variable may have the ability to alter a database, it should not be dependent on holding the stated information. A category is not restricted to coordinating, nor is it app friendly.
Szyperski, 2002	A software component is a synthesis unit with authoritatively defined configuration and explicit setting conditions. A software component can be freely distributed and third parties exposed to synthesis.
Microsoft Corp	A software component is an integrating, distribution, or conveyance device that provides styles of assistance within a data term adherence or limit of encapsulation.
D’ Souza and Wills, 1999	A part of a commodity is a kind package of software execution which can be independently generated and imparted. It has expressed and well-shown interfaces that it foresees for the services this backs up and for the different services.

In short, a component with a well-defined interface is a reusable, independent piece of software that is self-supporting to any task. The notable point to remember when constructing a component is the concept of reusability, whether or not a combination will recognize what the segment’s potential needs will be. Components may be placed on any device core, depending on the preconditions for operation and regardless of the device’s particular structure. In order to make the section usable for longer, effort must be made to ensure utility of the component beyond the needs of the current application (Gill and Grover, 2003).

1.1.2 General Component Properties

Modularity should be used as the basis for system design to develop good components. The criteria for determining a framework's modularity potential are defined in Table 1.2.

TABLE 1.2
Modularity Criteria of a Component

Criteria	Definition
Decomposability	A component-oriented approach to change will assist the product designer in characterizing a framework made up of less complex subsystems with a clear structure in between. Recognized subsystems (segments/objects/modules/...) may be sufficiently free to allow for a similar property for decomposability on each of them.
Composability	The component should be done in order to improve the reusability in different settings. Depending on their interface, each component may simply be freely joined with others.
Understandability	The framework element structure must help the comprehensibility of each of the components. In order to see each part, one might just need to take a quick look at the component itself and not in the frame into which it is incorporated.
Continuity	Continuity means that an obstacle to a neighborhood has a consequence nearby. Continuity is a major worry of programming maintenance as it could impact the cost of programming development. The law...

Table of contents

• Cover
• Half-Title
• Title
• Copyright
• Contents
• Preface
• Acknowledgments
• Authors
• Abbreviations
• Chapter 1 An Introduction to Component-Based Software Systems
• Chapter 2 Effort Estimation Techniques for Legacy Systems
• Chapter 3 An Introduction to Soft Computing Techniques
• Chapter 4 Fuzzy Logic-Based Approaches for Estimating Efforts Invested in Component Selection
• Chapter 5 Estimating Component Integration Efforts: A Neural Network-Based Approach
• Appendix A: Data Tables Used for Use Cases
• Appendix B: Review Questions
• Recent Trends
• Index