Formal Specification Methods for the
Improvement of Process and Product Quality
Satish Mishra1and Prof Holger Schlingloff12 1
Institut f¨ur Informatik, HU Berlin, 2
Fraunhofer FIRST, Berlin Rudower Chaussee 25 12489 Berlin
Abstract. Our research activities are focused on formal specification based product and process quality improvement of a software system. We start with a formal specification based pragmatic view on software specification, software refinement, software enhancement and software testing. These features are further explored for the improvement of prod-uct and process quality. On the basis of these features we propose a framework for the compliance of standard process improvement model CMMI(Capability Maturity Model Integration) and software product quality improvement.
1
Introduction
There are two main aspects of quality improvement activities in the development of the software projects: product and process view. Independently, in product and process quality improvement, formal specification methods have established their presence, starting from precise specification to verification and validation of system. However, formal specification features are less explored in the process quality achievement parallel to product development.
Our research starts with a pragmatic view on a process algebraic specification language CSP-CASL(Communicating Sequential Processes-Common Algebraic Specification Language)[1][2][3]. We define a distinct approach to the software specification, subsequently we deduce a concept of software refinement, enhance-ment and testing based on this approach to software specification. By giving formal definition to these concepts we develop a product and process quality achievement framework for the development of a software projects.
Product quality improvement is achieved through reusability of software ar-tifacts from the software refinement and enhancement. Formalism in a software specification and formal specification features plays significant role in the process quality improvement as a compliance of standard CMMI[6] practices parallel to development of software products. In the further sections we give a brief overview of our approach.
2
Pragmatic view on required preliminaries
In this section we describe required preliminaries of our research. These defi-nition are required to present our approach of of product and process quality improvement.
2.1 Formal specification
We consider a practical approach to describe a software system with a formal specification language CSP-CASL. Conceptually, a software system is consoli-dation of observational and internal behaviors. The description of observational behaviors is confined to a black box view of the software system. The description of internal behavior requires the knowledge of design decisions of the software system. The desired properties are formulated in terms of the observational be-havior, which is based on the internal behavior of the system. In this context we rewrite the syntax of CSP-CASL specification formalism (in Figure 1 (A)) as follows:
ccSpec ccSp=data SpObsAnd SpInt channel Ch process PObs;PIntend HereSpObsandSpIntrepresent the CASL specifications of the observational and internal data part of the considered system.PObs andPInt are the process part written in CSP [1][2][3], where the communication between processes of
PObs and PInt are the values of data types specified bySpObs and SpInt. And and 0;0 are concatenation syntax for external and internal data and process. In the description of a system we confine our approach to denotational semantics of CSP by considering traces and failures denotation of process which are sufficient to describe safety and liveness properties. Furthermore, the syntax and semantics of this definition remains the same as described in paper [1].
2.2 Software refinement
Generally, inception of a software system starts with abstract overview, which is further refined into a concrete implementation. Usually, in each step of re-finement some system details are added by preserving its abstract properties, in the construction a concrete implementation. We propose similar concept of refinement with formal specification language CSP-CASL in two steps approach; data refinement and process refinement. Complete formal definition is given as follows:
Definition 1. A CSP-CASL specification SP2= (Spr, Spri, P r;P ri) is the
re-finement of another CSP-CASL specificationSP1= (Sp, Spi, P;Pi), ifSP1and
SP2 satisfy followingData ref inementandP rocess ref inement conditions:
Data refinement
– (Σ(Sp) =Σ(Spr))∧(Σ(Spi)⊆Σ(Spri))
Process refinement
For all m ∈M od(Spr And Spri) there exist m1∈M od(Sp And Spi)such that
following conditions are satisfied:
– (T races(P r)m⊆T races(P)m1)∧(T races(Pi)m1⊆T races(P ri)m) – ∀t∈T races(P r)m,∀t1∈T races(P ri)m |(F ailures(P r/t)m⊆
F ailures(P/t)m1) ∧ (F ailures(P ri/t1)m⊆F ailures(Pi/t1)m1).
Here M od(Spr And Spri)|Σ(Sp And Spi) represents the M od(Spr And Spri) restricted to the Symbols(Sp And Spi); such that for all Symbols(Sp And Spi) there exist an injective mapping to the Symbols(Spr And Spri) and forall e∈
Axioms(SpAndSpi)|M odel(SprAndSpri)|Σ(Sp And Spi)|=e.Symbols(SpAndSpi) represents collection of all the declared data type, operations and predicate on those data types in the selected specification context.
This definition of refinement is used to analyze stepwise development of soft-ware system from abstract specification to implementation. A refinement rela-tion between specificarela-tions also provides a way to establish traceability among software development life cycle elements like requirement, design and test cases.
2.3 Software enhancement
Upgrades in a software system are very common practice for an industry. We formally define this concept as a software enhancement relation. Our approach of software specification allows us to elaborate software enhancement as process of adding new observable features or functionalities to the existing product by semantically preserving its existing features and functionalities.
Definition 2. A CSP-CASL specificationSP2 =(Spe, Spei, P e;P ei)is the
en-hancement of another specificationSP1 =(Sp, Spi, P;Pi), ifSP1andSP2hold
the following Data enhancement and Process enhancement conditions:
Data enhancement
– (Σ(Sp)⊆Σ(Spe))∧(Σ(Spi) ⊆Σ(Spei))
– M od(Sp And Spi) =M od(Spe And Spei)|Σ(Sp And Spi) Process enhancement
For all m ∈ M od(Spe And Spei) and m1 ∈ M od(Sp And Spi) those are true
for the data enhancement then the process enhancement relation should satisfy follows relation.
– T races(P)m1⊂T races(P e)m ∧ T races(Pi)m1⊆T races(P ei)m – ∀t∈T races(P)m1,∀t1∈T races(Pi)m1 |(F ailures(P e/t)m⊆
F ailures(P/t)m1) ∧ (F ailures(P ei/t)m⊆F ailures(Pi/t)m1).
Semantics of M od(Spe And Spei)|Σ(Sp And Spi)) is similar to the definition of data refinement as defined in above subsection. This definition of software enhancement is further used in the formal definition of change request in the scope of software product which is required by process quality improvement.
2.4 Test case and Test verdict
Testing is practical approach to validate the correctness of the system. Formal specification based development approach has established significant benefits for the improvement of process and product quality. Our approach of, CSP-CASL based formalism allows us to establish testing framework for generation and evaluation of the test suite. Test Suite is set of test cases. For a CSP-CASL specifications (Sp, Spi, P;Pi), each trace of process is considered as a test case, letT S is a test suite derived from this CSP-CASL specification. A test verdict for a test caseT C on a modelm∈M od(Sp And Spi) is defined as follows:
– Pass:T Cm∈T races(P;Pi)m∧if T Cm=< t1, t2..tn >|T Cm∈/F ailures(P;Pi/ < t1, t2..tn−1>)m
– Fail:T Cm∈T races(P;Pi)m∧if T Cm=< t1, t2..tn >|T Cm∈F ailures(P;Pi/ < t1, t2..tn−1>)m
– Inconclusive: not in the above two conditions
To ensure the quality of a software product, test activities should start at very early phases of the software development life cycle. An early initiation of the testing activities reduces a chance of error introduction in the testing activity itself. But some aspect of these activities should also be evolved as the develop-ment activity. Our definition of test case allows us to generate test suites from the abstract specification. Subsequently these test suites can be reused at the re-fined level of specification by applying same steps of refinement on specification as well as on the test suite.
3
Formal method based software specification and
software quality improvement framework
Here, we briefly describe our approach of software specification and its applica-tion in the product and process quality improvement framework. In the Figure 1 (A) we present our approach to software specification in terms of observational and internal properties of desired system. This approach of software specification is appropriate for the description of a software product in terms of step wise re-finement approach. Part B of this figure shows the concept of this specification in term of abstract and detailed view of the specified system. In the detailed description of system only internal properties are added by preserving system’s desired external behaviour. Part C of this figure presents a view on specification refinement(SP1, SP2), test suite(T S1, T S2) refinement and their commutative relation.
3.1 Process Quality Improvement
In our research, we evaluate given features of formal specification in the standard software process improvement model CMMI. We deduce a concept of process compliance with formal specification based software development. This approach
CSP-CASL specification
Data
SpobsAnd Spint
Channel Ch (optional) Process Pobs;Pint End E1 E2 E3 E4 Observable Abstract specification Detailed specification En • Data • Ops • Axioms e Internal e SP1 SP2 TS1 TS2 Refinement (R1) Refinement (R1) A B C
Fig. 1.Specification syntax and properties
leads the possibility of process compliance parallel to product development. In the next subsection we elaborate this concept of formal specification based de-velopment in the compliance of standard process model CMMI.
3.2 CMMI Process model and formal specification
CMMI is a framework for assisting organizations to improve their product de-velopment and maintenance process[6][8]. CMMI is based on the process areas which is cluster of related practices in an area. To evaluate the compliance of the CMMI process area with formal specification based software development we have developed the following grading schemes. These grading schemes are based on the achievement of the process area and its components.
Fully Contributed (FC):A process area is satisfied as FC if 90-100% of its specific goals are achieved using formal specification. A specific goal is achieved as FC when 90-100% of its specific practices can be performed by formal speci-fication.
Largely Contributed (LC):A process area is satisfied as LC if 60-89% of its specific goals are achieved using formal specification. A specific goal is achieved as LC when 60-89% of its specific practices can be performed by formal specifi-cation.
Partially Contributed (PC):A process area is satisfied as PC if 30-59% of its specific goals are achieved using formal specification. A specific goal is achieved as PC when 30-59% of its specific practices can be performed by formal specifi-cation.
Not Contributed (NC):A process area is NC if less than 30% of its specific goals can be achieved using formal specification. A specific goal is NC when less than 30% of its specific practices can be performed by formal specification.
On the basis of our in depth knowledge of CMMI implementation process re-quirement and formal specification based development approach we present our analysis in terms of above grading schemes. Out of 22 process areas of CMMI 6 engineering related process areas can be automatically achieved with formal specification based development at the grading level of LC. These process ar-eas are as follows Requirement management, Product integration, Requirement development, Technical solutions, Validation, Verification.
3.3 Product Quality Improvement
Formal methods have been already known in the product quality improvement. Based on some fundamental research work [7][9] we establish our test suite gen-eration method. In this method we consider a test case as a trace of CSP-CASL based process. The verdict of the test case is defined based on the given defini-tion in secdefini-tion 2. A formal method supports generadefini-tion of test suite in the early stages of software development cycle. These test suites has to be refined for the testing of implementation of specification. In the next subsection we describe basics of our approach of test suite refinement which is still under development stage.
3.4 Test suite refinement
To achieve the best quality in the product, test suite has to be generated at very early stage of software development life cycle. To execute generated test suite in the implementation test suite has to be refined according to the implementation model. In this respect, based on our definitions of refinement, test suite and test verdict we propose test suite refinement framework where abstract test suite can be refinement to concrete test suite[10]. Complete formalization of this method is still under development.
3.5 Conclusion
A pragmatic view on a software specification allows us to develop a process and product quality improvement framework. Based on given definitions; we formal-ize the software development life cycle and demonstrate the process compliance at the time of product development. Our framework allows us to prove software artifact reusability in the product refinement and enhancement. As a further re-search we are enhancing with the test suite generation and test suite refinement formalization. Further a tool is under development which will allow users to demonstrate the relation between given two specifications in terms of refinement and enhancement.
References
1. M. Roggenbach, CSP-CASL, A New Integration of Process Algebra and Algebraic Specification, Theoretical Computer Science 354, 2006.
2. Michel Bidoit, P. D. Mosses, CASL User Manual LNCS 2900 and CASL Reference manual LNCS 2960.
3. A. W. Roscoe, The Theory and Practices of Concurrency. Prentice Hall, 1998. 4. C. A. R. Hoare, Communicating Sequential Processes. Commun,ACM 21(8),1978. 5. Satish Mishra, Specification Based Software Product Line Testing: A Case Study,
Concurrency, Specification and Programming,2006.
6. S. Mishra, H. Schlingloff, Using Formal Specifications in the Implementation of CMMI, 16th Int. Conf on CS&P, Lagow, Poland, 2007.
7. Patricia D. L. Machado, Testing from Structured Algebraic Specifications, LNCS 1816,2000.
8. Capability Maturity Model Integration Home Page, http://www.sei.cmu.edu/CMMI/, April 2008.
9. M. C. Gaudel, Perry R James, Testing Algebraic Data Types and Processes: A Unifying Theory, Formal Aspect of Computing 10(5-6), 1998.
10. Elsa Estevez, Pablo Fillottrani, Algebraic Specifications and Refinement for Component-Based Development using RAISE, JCTS, 2000
