COTS (Commercial Off The Shelf)

Abstract. One of the least tested portions of software systems is error and exception handling. It also most critical situation for software. Error exception handling routines are the safety net for any system to handle unexpected circumstances such as when operating system  OS or hardware failures occur. As more critical systems are developed from commercial of the shelf  COTS software the robust ness of these applications to  perating system failures and in general to failures from third party software becomes increasingly critical. I try to present an approach and tool for assessing the robustness of COTS applications to failures from OS functions or other third-party COTS software. The approach con sists of wrapping executable  pplication software with an instrumentation layer that can capture record perturb and question all interactions with the operating system. The wrapper is used to return error codes and exceptions from calls to operating system functions. The efect of the failure from the OS call is then assessed. If the application crashes under these anomalous conditions, the application is determined to be non robust to a particular failing OS call. A failure simulation tool has been developed for testing the robustness of Win32 applications to these types of anomalous OS conditions.

1   Introduction

Many software projects are based on the integrated of independently designed components that are acquired on the marketplace rather than developmented within the projects itself. That type of components that developed by independently is named as COTS ( Commercial-Off-The-Shelf) components. The technology  was developed by Microsoft ( Components Object Model – COM and DCOM) provides mechanism of the COTS. Also Sun developed the Sun Java Bean on the mechanism of COTS.

COTS software is being used increasingly in developing mission critical systems. COTS software is any executable software for which source code is not provided or available for analysis. However; in general of the shelf software is any software that is not developed inhouse. The time and expense of developing software inhouse has supported developers of critical systems in the transportation medical devices and nuclear industries to adopt COTS software in the development of their critical systems. More recently the Windows 32 bit (Win32) platform which includes Windows 95/NT/2000/CE operating systems is being used in mission critical applications.

2   BACKGROUND

Robustness testing is now being recognized within the dependability research community as an important part of dependability assessment. To date robustness testing has focused on different variants of Unix software B.P. Miller and his research group at the University of Wisconsin wrote a tool called Fuzz that tested many variants of Unix system software to unusual, anomalous and purely random data.

In our previous studies of the Windows NT platform we analyzed the robustness of Windows NT OS functions to unexpected or anomalous inputs. We developed test harnesses and test data generators for testing OS functions with combinations of valid and anomalous inputs in three core Dynamically Linked Libraries (DLLs) of the Win32 Application Programming Interface (API); USER32.DLL, KERNEL32.DLL and GDI32.DLL. Results from these studies show non-robust behavior from a large percentage of tested DLL functions. This information is particularly relevant to application developers that use these functions. That is unless application developers are building in robustness to handle exceptions thrown by these functions their applications may crash if they use these functions in unexpected ways.

2.1 Supports the Exception Handling

The COTS helps programmer to debug the source. Programmers are able to generate codes correctly.  After selling on the market place, COTS components is tested by experince programmer. If you has a programmer, you can accept that COTS components is believe mostly. You can start to correct with your code.

2.2 Supports Software Independency

At rigth now, ares of the a specific software is being bigger than hitory. User that use want to components, they must be adapted to new system features. Hovewer, COTS brings some standarts. So each components by using COTS mechanism,  signs that it helps user what they do. So the software is written by using this standarts is being independency.

2.3 Deadlocks

COTS Components integration may cause deadlocks or other software anomolies within the system. The use of COTS software componentsin system constrcution presents new chellenges to system architectures and designers. Building a system from set of a COTS Components introduces,a specified set of problems.Many of the these problems arise because of the nature of COTS components. They are truly black-box and developers have no method of looking inside of box.

3    COTS Sub-Classes

COTS is standarts for programming. So COTS has some several sub class. Each sub-class presents different issues and problems.

• GOTS : Govermental COTS.
• MOTS: Modivable COTS.
• NDI: NonDevelopmental Item.
• OSS: Open Source Software.

4    ADVANTAGES and DISADVANTAGES

COTS has some advantages. It also has some disadvatages, too.

4.1  Advantages

• Available now, earlier payback
• Avoids expensive development & maintance
• Predictable licence costs& performance
• Rich in functionality
• Broadly used,mature technology
• Frequent upgrades often anticipate organization’s needs
• Dedicated support organization
• Hardware/software independence
• Tracks technology trends

4.2 Disadvantages

• Licensing and intellectual property procurement delays
• Up front license fees
• Recurring maintenance fees.Reliability often unknown/ inadequate; scale often difficult to change.
• Unnecessary features compromise usability, performance.
• Functionality, efficiency constraints.
• No control over upgrades/maintenance .
• Dependency on vendor.
• Efficiency sacrifices.
• Integration not always trivial; incompatibilities among vendors.
• Synchronizing multiple-vendor upgrades.

5     CONCLUSION

This position paper is a preliminary examination into the problem of matching between customers needs and package features. We argue that resolving conflicts that arise from the matching process is a critical issue for developing successful COTSbased systems. Without negotiation strategies, customers often focus on accepting already COTS solution (which will hardly meet their needs), rather than exploring new alternative solutions sharing mutual commitments. For example, customers may change their business practices in order to fit the product; products will probably need modifications that can range from simple customisations to large adaptations. As future work we need to investigate how to identify and characterise the various types of conflict that can arise from mismatches. Another major issue that needs to be addressed is the generation of negotiation strategies. Finally, once the approach will be fully defined, we need to empirically validate it in an industrial setting.

References

1. COTS Classificiton: A proposal by  Marco Torchiano ( Marco.Torchiano@idi.ntnu.no ) http://www.idi.ntnu.no/~marco/

2. Software- Implemented Hardware Fault Tolerance Experiments COTS in Space by P.P. Shirvani, N. Oh, E.J. McCluskey

3. Negotiating Requirements for COTS based  System by Carina Alves, Anthony Finkelstein(a.finkelstein@cs.ucl.ac.uk)

4. Correct and automatic assembly of COTS components: an architectural approach by Paola Inverardi  (inverard@univaq.it)  and Massimo Tivoli  (tivoli@univaq.it )

5. Qualıty Assurance For Space Instruments Buılt Wıth Cots by  Peter Buch Guldager, Gøsta G. Thuesen, John Leif Jørgensen

6. COTS Base System (CBS) Top-10 Lists, Lessons, Learned and Challenge by Berry Bohem at( http://www.cebase.org )