L O Analysis of Software Variants R Christian Lindig A Software Technology Group - C Technical University of Braunschweig Germany B R A Outline Computer platform diversity causes software diversity – software exists in variants. Most common strategy: separation at the module level and source code preprocessing for individual platforms. variant HP-UX Unix CPP Solaris Linux Aim: A better understanding of all the variants a specific source can generate. How many variants exist? How are variants related? How to generate a specific variant? Is there an easier way to create the same set of variants? Example – getopt.c /* This tells Alpha OSF/1 not to define a getopt prototype in <stdio.h>. Ditto for AIX 3.2 and <stdlib.h>. */ #ifndef _NO_PROTO #define _NO_PROTO #endif #ifdef HAVE_CONFIG_H #if defined (emacs) || defined (CONFIG_BROKETS) /* We use <config.h> instead of "config.h" so that a compilation using -I. -I\$srcdir will use ./config.h rather than \$srcdir/config.h (which it would do because it found this file in \$srcdir). */ #include <config.h> #else #include "config.h" #endif #endif #ifndef __STDC__ /* This is a separate conditional since some stdc systems reject ‘defined (const)’. */ #ifndef const #define const #endif #endif Result Result of an analysis: the variant lattice for a source file. 2 4 7,5 1 3 1 6 8 3 5 2 4 expressions 6 segments It shows: all variants and their relations, how to create them, and redundant expressions. Analysis technique: formal concept analysis. Concept Analysis Keywords accesschangecheckcreatedirectoryfile get groupinput modenew open outputownerpermissionprocessread removestatuswrite access chdir chmod chown creat fork fstat mkdir open Unix-System-Calls read rmdir write A (formal) context is a triple ( ; ; ) where and are O A R O A sets of objects and attributes respectively and is a R⊆O×A relation among them. AsetO(A) of objects (attributes) shares a set of common attributes (objects): def O0 a o O:(o; a) ={∈A|∀ ∈ ∈R} def A0 o a A:(o; a) ={∈O|∀ ∈ ∈R} [Krone, Snelting ICSE’94] defined O0 as ω(O) and A0 as α(A) Context Table access chmodchdir chown creat fork access Unix-System-Callsmkdirfstat open change rmdirread check write create directory file get group Keywords input mode new open output owner permission process read remove status write Concept Keywords accesschangecheckcreatedirectoryfile get groupinput modenew open outputownerpermissionprocessread removestatuswrite access chdir chmod chown creat fork fstat mkdir open Unix-System-Calls read rmdir write A concept c (O; A) of a context ( ; ; ) is a pair where = O A R O0 A and A0 O and also O ;A . = = ⊆O ⊆A Concepts are (partially) ordered: (O1;A1) (O2;A2)aO1 O2 (aA1 A2) ≤ ⊆ ⊇ The set of all concepts of ( ; ; ) is denoted by ( ; ; ). O A R B O A R Concept Lattice Keywords accesschangecheckcreatedirectoryfile get groupinput modenew open outputownerpermissionprocessread removestatuswrite access chdir attribute chmod chown object creat fork fstat mkdir file change create open Unix-System-Calls read rmdir write directory write read new attribute permission group process status access mode owner remove output input open get check rmdir chdir write read open fstat access mkdir chmod chown creat fork object Basic theorem of context analysis by Wille: Let ( ; ; ) be a O A R context. Then ( ; ; ) is a complete lattice, the concept B O A R lattice of ( ; ; ). O A R (O1;A1) (O2;A2) (O1 O2,(O1 O2)0) ∧ = ∩ ∩ (O1;A1) (O2;A2) ((A1 A2)0;A1 A2) ∨ = ∩ ∩ The maximal number of concepts is 2n where n max( O ; A ). = | | | | Ganter’s algorithm computes all concepts of ( ; ; ) with O A R time complexity O( B( ; ; ) ). | O A R | Concept Lattice Keywords accesschangecheckcreatedirectoryfile get groupinput modenew open outputownerpermissionprocessread removestatuswrite access chdir attribute chmod chown object creat fork fstat mkdir file change create open Unix-System-Calls read rmdir write directory write read new attribute permission group process status access mode owner remove output input open get check rmdir chdir write read open fstat access mkdir chmod chown creat fork object The Idea #if defined(E1) && defined(E6) && defined(E8) S3 #if defined (E3) && defined(E5) && defined(E7) S1 #endif #endif S6 #if defined(E2) && defined(E5) && defined(E7) S2 #endif #ifdef E3 #if defined(E4) && defined(E6) S4 #ifdef E8 S5 #endif #endif Expression Segment E1 E2 E3 E4 E5 E6 E7 E8 S1 • • •••• S2 ••• S3 ••• S4 •• • S5 •• S6 Encode the meaning of CPP-expressions into a binary relation (i.e. formal context) and analyze it using concept analysis [cf. Krone, Snelting, ICSE ’94]. A Model of CPP A configuration function f evaluates expressions e : ∈E f : 0;1 . E→{ } Avariant is a set of segments, selected by a configuration function f from a configuration table ( ; ; ): S E T f( ; ; ) s f(e) 1 for all (s; e) . S E T ={ ∈S| = ∈T} Configuration functions f1 and f2 are called equivalent (with respect to ( ; ; )), if they have the same effect: S E T f1 f2 f 1 ( ; ; ) f 2 ( ; ; ) É ⇐⇒ S E T = S E T [f ] denotes configuration functions equivalent to f . Expression f1 11 111 f2 111111 Segment E1 E2 E3 E4 E5 E6 E7 E8 S1 •••••• S2 ••• S3 ••• S4 •• • S5 •• S6 Variants T E E f 00011111 Segment E1 E2 E3 E4 E5 E6 E7 E8 S1 •••••• S2 ••• S3 ••• S4 •• S5(S; E) •• S6 • We find: [f ] is an equivalence class where f( ; ; ) S iff S E T = (S; E) B( ; ; ). ∈ S E T This means: every concept of the inverted configuration table describes an equivalence class. Proof sketch: there is no variant not described by a concept in ( ; ; ). S E T TT T EE EE EE S S S Variant Lattice The example’s variant lattice (i.e. the concept lattice of ( ; ; )). S E T 2 4 7,5 1 3 1 6 8 3 5 2 4 expressions 6 segments Each concept describes a variant and the canonical way to create it. T f 00110101 Segment E1 E2 E3 E4 E5 E6 E7 E8 S1 •••••• S2 ••• S3 ••• S4 •• • S5 •• S6 Variant Lattice vs. Configuration Lattice The variant lattice for the example: 2 4 7,5 1 3 1 6 8 3 5 2 4 expressions 6 segments And its configuration lattice [cf. Krone, Snelting, ICSE 94]. 8 3 6 1 7 ,5 5 3 4 1 2 4 2 expression segment Redundancies Are there expressions in my source file that can be safely eliminated? T Segment E1 E2 E3 E4 E5 E6 E7 E8 S1 •••••• S2 ••• S3 • •• S4 •• • S5 • • S6 An expression is called redundant if it can be removed from a configuration table without effect on any configuration function. Formally, e is redundant iff the following holds for any f : f( ; ; ) f( ; −; −) where − e and S E T = S E T E =E\{ } − ( −) T =T ∩ S×E Detecting Redundancies Redundant expressions show up in the concept lattice of the inverted configuration table as -reducible concepts: ∧ 1 4 6 (redundant) 1 3 2 5 2 6 4 4 7,5 1 3 1 6 8 3 5 2 4 expressions 6 segments Formally: e is redundant in ( ; ; ) if X ;e∉X ∈E S E T ⊆E exists in ( ; ; ) such that e 0 X0. S E T { } = X X e1 e2 e3 e4 e1 e2 e1'= X' e1'= X' e1 e2 e1 super concept super concept Problems #if defined(a) || defined (b) C1 #endif #if (defined(a) || defined(b)) && defined (c) C2 #endif #if !defined(a) && !defined(b) C3 #endif C1,C2,C3 Expression Segment a bc a b ∨ ¬ ¬ C1,C3 C1,C2 C1 •• C2 • C1 C3 •• Consider f with f a b; a; b 1then theory says: { ∨ ¬ ¬ }→ S C2;C2 is a variant. ={ } Problem: Theory does not take interdependencies into account (yet). Future work: use background implications to express dependencies. Future Work Extend theory with background implications to overcome limitations. Implementation – Concept analysis tool written in C available (send email!) – Rewrite of a concept analysis library in progress – Implementation will be based on new library Evaluation Conclusions Concept analysis is a promising theory for software re-engineering Variants generated from a source have a rich structure which can be effectively analyzed using concept analysis Variant description may contain redundant expressions which can be detected and removed This is work in progress – still much room for improvement and research..