This research involves furthering the component reuse evolution by integrating Object-Oriented Software Engineering with Cleanroom Software Engineering techniques and the Team Software Process into a Component-Based Cleanroom Software Engineering process. Cleanroom is a development process that has been used in the last decade, particularly for defense, safety-critical applications. It provides techniques for the development of code of very high quality by using specific coding guidelines, verification techniques and software reliability engineering. Object Oriented-Software Engineering, a more contemporary approach, specifically addresses domain analysis and modeling requirements for developing reusable components. The Team Software Process, a very new process, is a disciplined software process that provides a focus on project management for successful development of quality products.

The research will leverage the strength of each method into one integrated process for developing components of superior quality. An Object-Oriented scheme will be used for modeling. Cleanroom will provide the means for developing and verifying an internal implementation that can be proven to match its specification with statistically verified quality. The Team Software Process will be used throughout the development cycle to ensure the project is proceeding towards a successful completion.

In most traditional engineering fields, reuse of previously developed parts is explicit and expected for producing products most efficiently and of high quality. However, in the software engineering field, reuse is not yet a mainstream practice, and it will not become mainstream without deliberate focus. "A component is a piece of software that has been engineered to be reusable."[1] My research involves the development of such an engineering process, specifically designed at producing reusable software artifacts. While reuse does not require Object-Orientation(OO), the use of OO serves to ease the transition between a model of a real world problem and the software implementation to solve that problem. The process I will define will use OO.

It would be beneficial to perform domain analysis (identifying abstractions and relationships characteristic of the applications in the domain) prevalent in Object Oriented methods prior to beginning a Cleanroom type of process. In my research, I will develop a seamless integration of a front-end OO analysis phase into the rigorous Cleanroom process. In particular, I will investigate the use of the Unified Modeling Language (UML) as this front end. UML is an industry-standard, graphical modeling notation that provides a clear and precise description of an architecture and its components. I would like to determine if UML could be used to feed the black box, state box and clear box specification (described below) inherent in the Cleanroom process. The use of UML, and its associated documentation, can aid in the identification of exactly what a component does by potential "reusers".

Cleanroom uses the box structure methodology for producing a formal specification and design. A hierarchy of three types of box structures can rigorously describe the behavior of a system. The black box, which is developed in the specification phase, gives an external view -- user inputs and outputs, and hides all of the implementation details. The state box view (a finite state machine) partially exposes the data implementation while continuing to hide procedures. The clear box view partially (or fully) exposes procedures. Each of the last two views is developed in the design phase and may include reference to new black boxes in an iterative, stepwise refinement process. The development of the state box and clear box in the design phase could translate to systematically developing class variables and class methods. Original Cleanroom doctrine, developed prior to the current popularity of Object-Oriented languages, gives the freedom to apply the box structures to classes and objects development. However, specific guidelines for this translation have not yet been developed or documented. As part of my research, I would like to do this piece of work so others using Cleanroom with an Object-Oriented languages have sound methods to follow.

Underlying Cleanroom implementation is the use of structured programming concepts, which involve the use of disciplined control and disciplined data structures as defined in [3] and [4]. The disciplined control structures limit the programmer to the use of the following programming constructs: sequence, if-then, if-then-else, while, do-while, for loop, case/switch. These structures are nested over and over again in a hierarchical structure. Structured programming allows only single-entry, single-exit structures which eliminates the use of statements such as break, continue, goto, which eases the thorough verification process. These disciplined control structures were defined in the early 1970s and are as relevant today as they were over twenty years ago.

However, the original structured programming [3] and [4] needs to be updated to explicitly give guidelines on implementing disciplined data structures with Object-Oriented languages. Aggregate data structures, such as arrays and lists, need to be defined as anonymous data in which selected data elements are accessed only through defined, verified operations.[5] With object oriented languages, this can easily be implemented using class variables and verified class methods. In my research, I will develop and document guidelines, as with translating box structures to classes, on implementing disciplined structures with Object-Oriented languages.

A significant contributor to Cleanroom's high quality results can be attributed to the verification process. Software teams work to verify each other's artifacts prior to compilation and testing. Essentially, this involves reverse engineering the project to ensure the original specification is met. The code itself is verified against intended functions which are commented into the code to ensure the code actually implements these intended functions. A state box is developed from the actual clear box and it is compared to the intended state box. A black box is developed from the actual state box and it is compared with the intended black box (the specification). All this verification is done prior to compilation by the development team. Because of this, each developer knows that their work will be publicly scrutinized. This has the immediate psychological effect of causing the developer to produce simple, clean artifacts which are easier to verify, leading to higher quality products. This verification process, unchanged, will help produce components that can be trusted by "reusers".

The developers never compile their own code; instead an independent test group performs black box/functional testing only. The thorough verification practices eliminate the need for unit or structural testing. An area I will need to examine is whether this "black box testing only" tenet can be upheld when working solely with components, essentially analyzing Software Reliability Engineering for components. The black box testing serves to produce statistical input into the development of a reliability measure. A key component for a successful software reuse evolution is giving a potential "reuser" confidence that a component will perform the stated function, free of defects. The reliability measure, specifically Mean Time to Failure (MTTF), could be an indispensable way of giving added confidence to the "reuser" on the quality of the component.

The Team Software Process (TSP) will underlie the Component-Based Cleanroom Software Engineering process. TSP, the successor to the Personal Software Process (PSP), is a disciplined process for producing quality software products via a team of developers. Essentially, I will be defining TSP in the OO, component-development domain. TSP gives guidelines on the entire software development process. The practices that will principally be extracted from TSP for the Component process will be project management, estimation and tracking. Producing reusable components is important; producing reusable components on-time and at an established cost is essential for successfully producing software "faster, better and cheaper". TSP adds these dimensions to the process.

[1] Jacobson, Ivar, Griss, Martin, and Jonsson, Patrik Software Reuse, Addison Wesley, 1997.

[2] Jacobson, Ivar, Object-Oriented Software Engineering, Addison-Wesley, 1992.

[3] Dahl, O.J., Dijkstra, E.W., and Hoare C.A.R, Structured Programming, Academic Press, 1972.

[4] Linger, R.C., Mills, H.D. and Witt, R.I., Structured Programming: Theory and Practice, 1979.

[5] Rosen, Steven J., Design Languages for Cleanroom Software Engineering, in Proceedings of the Hawaii International Conference on System Sciences, 1992.