Refining Complexity Metrics of Component Based Softwares by taking Average Use Factor in Black Box Testing

ABSTRACT: We propose to compute the complexity metrics of component based software in more justified way by taking considerations of their using frequencies. The complexity metrics calculation of the component Based software’s by using black box testing is still not refined. The reason is that the various components are not used by the end users uniformly. Again, use of various components depends upon user to user as per their requirements. So therefore calculating straight forward their complexity on the basis of number of components, their interfaces and data types are not sufficient. We must add the factor of their (AUF) average use factor by the customers of different components. As we know that every algorithm or program have 3 complexity states i.e . a) Best Case b) Average case and c) Worst case. As we know that each and every components of software is not used uniformly by the users. So calculating merely on the basis of their no of components, interfaces and data types predicts only theoretical complexity of that software. If we wish to calculate more justified complexity metrics then we must normalize these components on the basis of their frequency of use in normal routine. As it’s quite possible that some modules or components are rarely used by common users. In this case those components hardly influence the complexity of that software. Thus we can reduce significantly the complexity of component based software which was earlier hypothetically calculated very high.


INTRODUCTION
Component-based software development (CBD) is an emerging discipline that promises to take software engineering into a new era. Building on the achievements of object-oriented software construction, CBD aims to deliver software engineering from a cottage industry into an industrial age for Information Technology, wherein software can be assembled from components, in the manner that hardware systems are currently constructed from kits of parts.
This volume provides a survey of the current state of CBD, as reflected by activities that have been taking place recently under the banner of CBD, with a view to giving pointers to future trends. The contributions report case studiesselfcontained, fixed-term investigations with a finite set of clearly defined objectives and measurable outcomeson a sample of the myriad aspects of CBD. This paper includes chapters dealing with COTS (commercial off-the-shelf) components; methodologies for CBD; compositionality. We use case studies and complexity metrics formula and multiply it with the assumed usability factor points for each component to calculate the complexity. We can use the statistical techniques for the validity of results. The proposed algorithm can be implemented in any suitable programming language or Case Study. In this case those components hardly influence the complexity of that software. Thus we can reduce significantly the complexity of component based software which was earlier calculated very high.

Proposed work:
We use case studies and complexity metrics formula and multiply it with the assumed usability factor points for each component to calculate the complexity. We can use the statistical techniques for the validity of results. The proposed algorithm can be implemented in any suitable programming language or Case Study.         The first factor is static. As memory occupied is a static feature and its not varies user to user .The second factor is variable user to user depending upon their habit and needs.

Microsoft Word 2007
However whatever the user's age , education , need or habit to use a software package and its components ; a user can't use all the components uniformly. Thus the execution of such components does not affect the system uniformly and thus we must made sufficient provision to reduce this theoretical complexity calculation.
In the above table we can say that rarely used software components less affects the complexity of software as most of time they only occupies the memory of secondary storage which is available in abundant and not a critical resource .

MS Word Software Components:
MS word is the biggest bundle of software components available in the package. For simplification we choose some selected components amongst them for case study : We can use the same process for the micro software components for complexity computations in black box model.

Advantage of WCCM(BBAU) over othe available available blackbox component based software complexity calculation methods:
Advantage of WCCM(BBAU) Component Complexity Metric (Black Box Average Use method) is more realistic and simpler than all available complexity determining methods in black box methods. Its include the factor of Average Use factor which earlier ignored . This reduces significantly the complexity computation than others who calculates theoretically without considering end user requirement.

CONCLUSIONS
The earlier techniques ignores the usability factor of the different software components which are the most major aspect and varies user to user . We propose to compute the complexity metrics of component based software in more justified way by taking considerations of their using frequencies. The complexity metrics calculation of the component Based software's by using black box testing is still not refined. The reason is that the various components are not used by the end users uniformly. Again, use of various components depends upon user to user as per their requirements. So therefore calculating straight forward their complexity on the basis of number of components, their interfaces and data types are not sufficient. We must add the factor of their average use by the customers of different components. As we know that every algorithm or program have 3 complexity states i.e . a) Best Case b) Average case and c) Worst case. As we know that each and every components of software is not used uniformly by the users. So calculating merely on the basis of their no of components, interfaces and data types predicts only theoretical complexity of that software. If we wish to calculate more justified complexity metrics then we must normalize these components on the basis of their frequency of use in normal routine. As it's quite possible that some modules or components are rarely used by common users. In this case those components hardly influence the complexity of that software. Thus we can reduce significantly the complexity of component based software which was earlier hypothetically calculated very high.
Although the CBSD is increasingly being adopted for software development, because of its advantages like reduction in development effort, time and cost , increase in quality with many others. But it still consists of a number of issues or factors that affect many aspects of CBSD like integration and testing effort and affect the produced software cost, maintainability, quality etc Many of these factors or issues can be resolved by using the independent components or the components with low coupling. Thus a technique has been proposed for the component based software development organizations to be followed during the component based software development. Thus it will help in reducing the integration effort, testing effort, cost and providing the more maintainable and good quality software system. After adding the component using frequencies we can more justify the complexity metrics.