Cleanroom Software Development using Aspect - Oriented Programming
Natacha Govan Universidade Nova de Lisboa – Faculdade de Ciências e Tecnologia [email protected]
Abstract CSD software engineering is clamed to yield software The issue of this article is pertaining with, Cleanroom that is correct by mathematically sound design, and Software Development using Aspect–Oriented software that is certified by statistically-valid testing. Programming. Reduced cycle time results from an incremental Cleanroom Software Development (CSD) is an development strategy and the avoidance of rework engineering process to develop software that is high in [Foreman 05]. quality and with a certified level of reliability. It is well-documented that significant differences in cost Aspect-Oriented Programming (AOP), also known as are associated with errors found at different stages of the Aspect-Oriented Software Development (AOSD), is an software life cycle. By detecting errors as early as approach to software development, which tends to possible, CSD reduces the cost of errors during separate concerns, or breaking a program into distinct development and the incidence of failures during features. operation; thus the overall life cycle cost of software The understanding of the meaning and the usage as well developed under CSD can be expected to be far lower as the functionality of the CSD can be very helpful, as it than industry average [Foreman 05]. can enable one to produce a software and in a developing process. Typical characteristics of CSD include: The present paper analyses the relationship that may • Software development based on formal methods exist between the Cleanroom Software Development and • Incremental implementation under statistical the Aspect - Oriented Programming. quality control • Statistically sound testing. Key Words: Cleanroom Software Development, Aspect-Oriented Programming, Aspect-Oriented Software Aspect Oriented Software Development (AOSD) is a Development, Formal Methods, Statistical Quality set of emerging technologies that seeks new Control, Testing, cross-cutting, AspectJ. modularizations of software systems. AOSD allows multiple concerns to be separately expressed but nevertheless be automatically unified into working 1. Introduction systems [RETECM]. Separation of concerns is the process of breaking a program into distinct features that The name Cleanroom Software Development (CSD) overlap in functionality as little as possible. Specifically came about from the electronics industry, where a cross-cutting concerns are aspects of a program which physical cleanroom existed in order to prevent the affect other concerns. As an advance in modularization, introduction of defects during hardware fabrication. that measures the extent to which computer programs Harlan Mills was the proponent of CSD concept have been composed out of separate parts called modules. [Mills 87], and thereafter several authors (such as) have reported its use. The use of CSD was reported in early nineties in the military projects [Foreman 05]. 1.1. Motivation CSD process have been moving away from the traditional, craft-based software developing practices to a The current paper, aims at identifying the possible more rigorous and engineered based practices, and intersections between CSD and AOSD. In addition, these focusing on the prevention of the imperfections rather both software aspire to produce higher quality software than removing them. In addition, one can find that CSD with less error. process is in concordance with the capabilities The main concern is to analyze, understand and specifications that are expressed in the Communicating conclude whether the techniques with regards to CSD that Sequential Processes (CSP), [BH 05]. were mentioned above are applicable in AOSD or not.
1.2. Survey Methodology used to confirm that the design is a correct implementation of the specification. Therefore, the The present section explains the method used in order specification must define that function before design and to achieve the objective mentioned in the above section, functional verification can begin. Verification of program which is to identify the intersection between the CSD and correctness is performed through team review based on AOSD worlds. correctness questions. There is no execution of code prior to its submission for independent testing [Foreman 05]. Since it has been experienced a certain difficulty in getting a direct outcome from CSD by using AOSD, the This method can effectively detect changes in the aim is to associate and combine AOSD with CSD process that may affect its quality. characteristics, that were mentioned in the section 1, As described by [Hausler 94], the Cleanroom namely formal methods, statistical quality control and methodology provides a complete discipline within which statistically testing. Therefore, the current paper will software personnel can plan, specify, design, verify code, assist one in finding out whether there is a significant test and certify software. In a Cleanroom development, relationship between these two software development correctness verification replaces unit testing and processes, and consequently, the key common, or not, so debugging. After coding is complete, the software common points that may be of significant relevance in the immediately enters system test with no debugging. All test errors are accounted for from the first execution of the software development. However, it is important to bear in 1 mind that these software are designed to deliver a higher program with no private testing allowed. and a better software quality. 2.1. CSD development based on formal In addition, it is also known that by using CSD with methods another development processes can deliver a significant and quite accurate result, since every step of the process Formal methods use mathematical and logical is tested in order to solve the errors that may come about formalizations to find defects early in the software during the software development. At the same time, it is development lifecycle [Langari 05]. These two methods easier to correct the errors as they arrive in the beginning have been used separately to improve software quality of the program life cycle rather than at the end. since the 1980's. The combination of the two methods may provide further quality improvements through 1.3. Organization reduced software defects. This result, in turn, may reduce development costs, improve time to market, and increase This paper is organized as follows: overall product excellence. Defects in computer software Section 2 highlights the objectives, the formal are costly. Their detection is usually postponed to the test methods, the statistical quality control and the statistically phase, and their removal is also a very time consuming testing of the Cleanroom Software Development. and expensive task. The objective of this study is to Section 3 describes and clarifies Aspect-Oriented investigate the economic impact of an inadequate Programming with regards to its functionalities, infrastructure for software testing in the U.S - National objectives and the language that is used in this software. Institute of Standards and Technology (NIST). Finally, Section 4 states the findings concerning the The advantages of finding defects in the early stages are interrelationship between CSD and AOSD along with the decreased cost and increased quality. Results show that, related works. by using formal methods, a higher quality will be achieved and the software project can also benefit from 2. Cleanroom Software Development tools that usually support those methods [Langari 05].
Formal technical reviews or inspections find problems As it has been mentioned on the above sections CSD before they become part of design that will be used for is a process that aspires to create software without errors coding. This leads to higher quality products and saves and thus a high quality characteristic is attached to this time because errors are found early during the software. development process [Becker et all 01].
In CSD development, a key principle is that a computer program is an expression of a mathematical function. The Box Structure Method [Mills 98] is used for specification and design, and functional verification is 1 Testing performed by the own developers 2.2. Statistical quality control software in terms of reliability and confidence [Foreman 05]. Incremental development as practiced in CSD provides a basis for statistical quality control of the Cleanroom certification can reduce time to market development process. Each increment is a complete because you are not spending time testing and fixing iteration of the process, and measures of performance in when you need not be. When you reach the quality level each increment (feedback) are compared with desired, you can ship, even if complete path coverage is preestablished standards to determine whether or not the not achieved. Keep in mind that this is totally dependent process is "in control." If quality standards are not met, on the usage model. An inaccurate usage model and testing of the increment ceases and developers returns to probabilities result in inaccurate statistics. Statistical the design stage [Foreman 05]. usage testing is also more efficient than coverage testing. Re-work also tends to be reduced. More importantly, Cleanroom engineering achieves intellectual control maintenance teams are not held hostage supporting post by applying rigorous, mathematics-based engineering release error correction. Keep in mind that if the software practices, establishes an errors-are-unacceptable attitude was developed poorly to begin with, certification will and a team responsibility for quality, delegates ultimately tell you that. Do it right the first time [Oshana development and testing responsibilities to separate 96]. teams, and certifies the software's mean time to failure through the application of statistical quality-control 3. Aspect-Oriented Software Development methods [Cobb 90]. Traditional developers paradigms support 2.3. Statistically sound testing modularization techniques such as procedures, classes or packages to decompose a system into different parts for managing (spiting) complexity for reuse sake. However, CSD does not rely on unit testing performed by the there are often several ways of performing that developers. decomposition. Focusing on a specific concern leads to a The cleanroom concept asserts that this type of unit giving decomposition, while other concerns that were testing should be private to the programmer. Unit testing relegated (e.g. persistency, logging, synchronization), are is actually considered dangerous because it tends to find spread all over the modules. many of the superficial defects and lets some of the other AOSD main characteristic is the ability to allow more important errors slip through [Oshana 96]. multiple decomposition of a system to fulfill separation of concerns. Cleanroom uses a formal statistical approach to testing that can indicate the quality of the software and stopping As described by [Kiczales 97], and his team at Xerox criteria as well. This approach differs from the traditional PARC originated the concept of AOP. This team also approach, in which testers assume there are errors in the developed the first and most popular AOP language, software and set out to find as many as possible, with the AspectJ. Aspect-oriented Programming is one of those faulty assumption that if enough errors are found and ideas that seems new but has actually been around for fixed, the software quality would improve. Cleanroom quite a while. Many people contributed to the body of operates under the realistic assumption that it is not knowledge available today, and many can lay claim to possible to test quality into a product. Certification (the being a founder. cleanroom term for testing) is performed to certify the software reliability, not test the software in the classical An IBM research team emphasized the continuity of sense [ Oshana 96]. the practice of modularizing concerns with past programming practice, and offered the more powerful In CSD testing is viewed as a statistical experiment. A (but less usable) HyperJ and Concern Manipulation representative subset of all possible uses of the software is Environment, which have not seen wide usage. HyperJ is generated, and performance of the subset is used as a a tool that supports advanced, "multi-dimensional" basis for conclusions about general operational separation and integration of concerns in standard performance. In other words, a "sample" is used to draw JavaTM software. This support facilitates improved conclusions about a "population." Under a testing modularization, adaptation, composition, integration, and protocol that is faithful to the principles of applied even non-invasive remodularization of Java software statistics, a scientifically valid statement can be made components [Tarr 00]. about the expected operational performance of the Aspects are modular units that treat concerns of object- 3.3. Statistically testing oriented systems that otherwise would crosscut the inheritance hierarchy of an object-oriented system. The statistical test rejected the null hypotheses for the These language constructs are intended to reduce time to change requirements, and yield pre and post- scattering of code to treat a concern throughout a system, validation prototypes. The confidence interval for and tangling of that code with the code of the rest of the implementation and test time indicated that the null system [TOHS 99]. hypotheses test was obtained with a low precision. In fact, we expected benefits from implementing and testing the 3.1. Formal methods software with the progressive approach. When progressively implementing and testing The difficulties in generalizing formal methods tools functional requirements, the programmer does not have to developed for a particular context to a framework where worry with persistence and distribution issues and vice- they are applied to a variety of input languages are versa, decreasing implementation and test complexity. nontrivial, but crucial to tool integration. Practical These wide confidence intervals suggest that others software engineering issues of connections among tools, studies should be performed to better evaluate the differences in tool maturity, and missing links in a progressive approach impact in implementation and tests verification chain also must be considered if integrated [Soares 04]. formal methods are to become a reality. The Common Aspect Proof Environment (CAPE) is intended to If separate concerns can be tested separately, testing an facilitate practical tool integration for the relatively new AOP application becomes easier than testing a traditional area of formal methods for aspect-oriented programming application, where the crosscutting concerns are tangled and software development. By dealing with such issues, with the base code. This testing consists in order to test besides providing tools for verifying and analyzing the aspects separately from the base code [CTR 05]. aspects, the CAPE is an important step in developing Incremental AOP testing starts by applying branch techniques for incorporating isolated tools into integrated coverage to the base code, without considering the extensible proof environments [E 07]. aspects. The resulting test suite provides a way to expose those errors that affect the principal decomposition. After 3.2. Statistical quality control that, the method goes on considering the first crosscutting concern. It is woven into the base code and the coverage AOP may also be a great addition to quality for the previous suite is evaluated on this composition. professionals’ toolboxes. Using an AOP language, we might be able to test application code automatically The existing test suite is expected to be lacking in without disturbing the code. This would eliminate a covering the composition, because new code has been possible source of error. introduced and because aspects have possibly modified the base control structure and behaviour. Therefore, a The issues concerning quality are closely related in second collection of test cases must be defined, in order adopting the AODS methods as quality is indeed to reach an adequate coverage of this second version of important but is not the only feature that one can look at. the application. Incremental AOP testing continues in this AOSD is a new paradigm. As did other paradigms when way, until all aspects are weaved and the final, complete they were new (e.g., object-oriented software application is tested [CTR 05]. development), this one will take time to be adopted widely because it involves a learning curve. First we must The incremental approach may lead to a more learn basic techniques and mechanics, then advanced effective debugging, because it separates the bugs in the techniques, and then how to best apply the techniques and base code from those in the aspect code or deriving from when they are most appropriate. Tools will play a major the interaction between base code and aspects. The test part in industry adoption of AOP. In addition to compilers suites are, in fact, divided according to the concerns and editors, we need tools to help us reason about defined during the design and development phases. Thus, systems, identify potential cross-cutting concerns, and tests should be easier to understand, being better help us test in the presence of aspects [Pollice 04]. modularized [CTR 05]. The incremental AOP testing is considered in the context of coverage (white-box) testing. However, it can be used also with a black-box approach, in that it is focused on splitting the test cases according to the system functionalities, which might belong to the principal decomposition or might be crosscutting concerns [CTR 5. Conclusion 05]. Regarding the analysis so far made in the present 4. Related Work paper, one can see that some similarities were found. A wide range of publications and studies is available Here I briefly introduce some CSD and AOSD about AOSD and the respective formal methods in the methods. crosscuts of an object-oriented system, however one can [Langari 05] proposed a new approach to software face a difficulty in generalizing formal methods, quality combining cleanroom methodologies and formal particularly under the context described in section 3. methods. It has been noticed that AOSD has the necessary toolbox to provide a certain level of quality, but does not In [Cobb 90] the concept of cleanroom engineering of seem to be sufficient, as a deep knowledge for improving software is introduced. Cleanroom engineering achieves the techniques mechanism is required in AOSD. intellectual control by applying rigorous, mathematics- Therefore, a continuous learning would be adequate. With based engineering practices, establishes an errors-are- regards to the testing the AOSD, it is felt that the unacceptable attitude and a team responsibility for language used can be appropriate to detect and thus quality, delegates development and testing responsibilities eliminate the possible errors to separate teams, and certifies the software's mean time Bearing in mind the investigation conducted, it can be to failure through the application of statistical quality- noticed that both software’s development processes are control methods. A typical project is used to explain the crucial in the life cycle of the software. concepts and procedures It can be further suggested that the CSD method could be applied in the development of the majority of software, In [E 07], is an extensible environment for different in order to decrease the probability of making an error aspect verification and analysis tools and modules over and the respective costs. The sooner the error is detected various aspect languages. It is being developed as one of the better it is as it will also the trouble to detect the error the primary tasks of the Formal Methods Laboratory of after the software has been completed, and as mentioned AOSD-Europe. The design and implementation is mainly previously, this is possible as testing is done in most of being done at the Technion, with tools contributed from the steps of software development.The quality expected is the Technion and from other AOSD-Europe sites, and in also higher due to the fact that all imperfections and particular INRIA, Twente and Lancaster. errors are avoided.
The person most commonly associated with AOP is AOSD is one of the ways to seek and attain a better Gregor Kiczales , currently at the University of British software system, however nothing can be considered Columbia, where he works on software modularity perfect for every situations, so in developing software one research. From 1984 to 1999, Kiczales worked on AOP at has to consider constraints that may come about. Every the Xerox Palo Alto Research Center (PARC) and was a situation has its unique particularity namely its language, leader in developing implementations of it. the working environment as well as the process techniques. Therefore specific software may be required In [Tarr 00] Peri Tarr is a research staff member at for each situation. IBM's Thomas J. Watson Research Center. She co- Aspect-oriented Programming is one of those ideas invented, and conducts research in, multi-dimensional that seems new but has actually been around for quite a separation of concerns (MDSOC). Ms. Tarr leads the while. HyperJ development effort, provides MDSOC support for The Cross-cutting concerns is more like redoing,, Java, and has been exploring issues in multi-dimensional simplifying, cleaning and organizing its structure without separation of concerns throughout the software lifecycle. changing its results and consequently improving its Harold Ossher is a research staff member at IBM's readability. Thomas J. Watson Research Center. He co-invented subject-oriented programming in 1993 and multi- AOP is designed to handle cross-cutting concerns by dimensional separation of concerns and hyperspaces in providing a mechanism, the aspect, for expressing these 1998-99. Mr. Ossher manages a group that conducts concerns and automatically incorporating them into a research in and provides tool support for MDSOC and system. AOP does not replace existing programming applies the composition concepts and tools to other paradigms and languages; instead, it works with them to domains. improve their expressiveness and utility. It enhances our ability to express the separation of concerns necessary for a well-designed, maintainable software system. Some Loingtier, and John Irwin (1997). "Aspect-Oriented concerns are appropriately expressed as encapsulated Programming", Proceedings of the European Conference objects, or components. Others are best expressed as on Object-Oriented Programming, vol.1241, pp.220–242. cross-cutting concerns [Pollice 04]. The paper originating AOP.
A final note to the investigation is that the usage of [Langari 05] Zarrin Langari, Anne Banks Pidduck CSD by AOSD in developing software programs can be Quality, cleanroom and formal methods. quite advantageous since one can actually experience the efficiency and the effectiveness that particular software [Linger 94] Linger, R.C. "Cleanroom Process Model." developed under this circumstance can provide. This is IEEE Software 11, 2 (March 1994): 50-58. therefore a consequence of offering reliability needed to use the software plus to the fact that the final product is [Mills 87] Mills, H.; Dyer, M.; & Linger, R. "Cleanroom free of any errors. Software Engineering." IEEE Software 4, 5 (September 1987): 19-25. 6. References [Mills 98] Harlan D. Mills, Stepwise Refinement and [Becker et all 01] Shirley A.Becker, Boris Beizer, Verification in Box-Structured Systems, Computer, v.21 Micheal Deck P.A.Hausler, Tove Janzon, Richard Linger n.6, p.23-36, June 1988. Harlan Mills, C.J.Trammell. Cleanroom Software Engineering, Inc - International Business Machines. [Oshana 96] Oshana, R., "Quality Software via a Cleanroom Methodology," Embedded Systems [BH 05] Guy H. Broadfoot and P. J. Hopcroft (2005). Programming, Sept. 1996, pp. 36-52. "Introducing formal methods into industry using Cleanroom and CSP". Dedicated Systems e-Magazine. [Pollice 04] Gary Pollice Worcester Polytechnic Institute Retrieved on 2006-04-27. 27 0 2004.
[Cobb 90] Cobb, R.H. Mills, H.D. “Engineering [RETECM] R. E. Filman, T. Elrad, S. Clarke, and M. software under statistical quality control”, Nov 1990, Ak¸sit, editors. Aspect-Oriented Software Development. IEEE Software SET, Annapolis, MD. Addison-Wesley,Boston, 2005.
[CTR 05 ] Mariano Ceccato, Paolo Tonella and Filippo [Soares 04] Sérgio Soares; BORBA, Paulo. “Towards Ricca ”Is AOP code easier or harder to test than OOP Progressive and Non-progressive Implementation code?“ ITC-irst Centro per la Ricerca Scientifica e Approaches Evaluation”. In: 1st Experimental Software Tecnológica Engineering Latin American Workshop - ESELAW'04 - < URL: http://star.itc.it/tonella/papers/wtaop2005.pdf>. SBES'04, 2004, Brasília. 1st Experimental Software Engineering Latin American Workshop - ESELAW'04, [E 07] EyalDror, et al, A Preliminary Implementation of 2004. the CAPE, AOSD-Europe Deliverable D71, AOSD- Europe-Technion-7, March 2007. [Tarr 00] Peri Tarr, Harold Ossher HyperJ multidimensional separation of concerns (MDSOC) for nd [Foreman 05] Foreman, John (2005). Cleanroom Java; Proceedings of the 22 century international Software Engineering. Software Technology Roadmap. conferenceon Software engineering, 2000, pages 734- Software Engineering Institute (SEI). Retrieved on 2006- 737. 04-27.
[Kiczales 97] Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc