Crosscutting Concerns in Embedded Software

Overview of our work on crosscutting concerns in embedded C code, published at ICSE 2006 and AOSD 2007. Presentation used in software architecture course at TU Delft in 2008.

The presentation covers error handling in C, parameter checking, logging, tracing, and the use of static intra-procedural analysis to detect problems.

Transcript

1. Crosscutting Concerns In Embedded Software Arie van Deursen May 2008 Joint work with Magiel Bruntink, Tom Tourwé, Maja d’Hondt
2. 2 “Separation of Concerns” “Any given problem involves different kinds of concerns, which should be identified and separated to cope with complexity and to achieve the required engineering quality factors, such as adaptability, maintainability, extendibility and reusability” E.W. Dijkstra, 1976 “A Discipline of Programming”
3. 3 Crosscutting Concerns • Dominant decomposition – Prime result of “separation of concerns” – Isolates key concerns in layers, packages, classes, functions, ... • Crosscutting concerns: – Mismatch with dominant decomposition – E.g.: error handling, logging, security,...
4. 4 Questions 1. What crosscutting concerns did you encounter? 2. Are such concerns a problem? 3. Which architectural implications do you see? 4. Which reverse engineering implications do you see?
5. 5 Composition Risks • Scattering – Single concern (“undo”, “error handling”) scattered across many different components • Tangling – Implementation of your primary concern (“move wafer”) necessarily tangled with several crosscutting concerns
7. 7 Crosscutting Concerns (I) a) “Every public function should check its parameters before using them. ...” b) “Every public function should trace its parameters just after entry and just before exit. ...” c) “After invoking any C function, the error code returned must be checked...” d) “Rec. 8@103: ... if you rethrow an exception ... set the InnerException property of the new exception to the caught exception...” e) “Rule 8@105: Always log that an exception is thrown.”
8. 8 Crosscutting Concerns (II) a) “The user should be able to undo any command” b) “Every figure should notify its observers about any change made” c) “Every component should offer the Lifecycle interface to start or stop execution.” d) “Every component should offer an invoke method to allow pipelining a series of commands” e) “All exceptions thrown in lower layers should be wrapped”
9. 9 Abstraction Richard Gabriel: • Abstraction in programming is – the process of identifying common patterns – that have systematic variations; • An abstraction – represents the common pattern and – provides a means for specifying which variation to use. http://www.dreamsongs.org/Files/PatternsOfSoftware.pdf
10. 10 Characteristics • Quantification: – Do something for selected behavior, functions, classes, methods, layers, exceptions, ... • Obliviousness: – Can we decompose the system so that the affected design elements need not be aware of this? Filman and Friedman, WASC 2000, Aspect-Oriented Programming is Quantification and Obliviousness.
11. 11 Aspect-Oriented Programming • Composable crosscutting concerns • Static quantification: – Extend classes with method m • Dynamic quantification – Execute advice at explicitly specified execution points (“joinpoints”) • Weave relevant code into application
14. 14 Our Aspect Research • What can aspects mean for existing systems? – Prevent further decay? – Restructure to aspects? – Exploration support for crosscutting concerns? • Projects: – Java, analysis of open source systems, AspectJ – C, embedded systems analysis Focus for rest of talk
15. 15 • Analyze 15 Mloc ASML C code base – World leader in lithography systems • Objectives – Effort reduction – Lead time reduction – (Reliability improvement) • Means – Address way crosscutting concerns are handled – Code as well as design level • Partners: ASML, ESI, UT, TU/e, CWI, TUD The Ideals Project Idiom Design for Embedded App’s on Large Scale
16. 16 Approach • Analyze present situation – Are there any problems? • Envision target situation – Are aspects the solution? • Analyze migration issues – Can we get there for existing components?
17. 17 Present Situation • Language used is C – No support for crosscutting concerns • Solution – Coding conventions / idioms – Prescribed in architecture documents for most important crosscutting concerns – No fixed approach for other crosscutting concerns Patterns are a sign of language weakness?
18. 18 Example I: The Parameter Checking Concern • Each public function should check its parameters – Reduce risk of null pointers errors at integration time • Check should occur before first use / dereference – But can be anywhere in the call chain • Check depends on parameter’s kind: – input, output, output pointer.
19. 19 Example Code int align (int* data_ptr) { int error = OK; char* func_name = “align”; if ((error == OK) && (data_ptr == (int*) NULL)) { error = PARAMETER_ERR; LOG(error, 0, ("%s: input parameter '%s' is NULL.", func_name, “data_ptr")); } . . .
20. 20 Code Size Implications Concern LOC % Tracing 1539 8% Error Handling 1716 9% Memory Handling 965 5% Parameter Checking 1441 7% Total 5561 29% • CC : component for data conversion • 19 KLOC, 11 files.
21. 21 Are there any problems? • Parameter checking fault model: – Check omitted – Wrong check, confusing in- / output – Unnecessary check • Develop checker for correct usage of idiom – Verify all paths from param to its first use – Data and control flow analysis – Plugin to GrammaTech’s CodeSurfer slicing and program analysis tool
22. Parameter Checking Findings Size Kloc Deviations reported Unintended Intended CC1 3 8 0 8 CC2 19 65 58 7 CC3a 12 23 16 7 CC3b 98 53 41 12 CC4 14.5 31 24 7 CC5 15 5 4 1 161.5 185 143 (77%) 42 (23%) 0.9 missing checks per KLOC (1 in 4 params not checked)
23. 23 Example II The Error Linking Concern • Proper error logging essential for – Activating correct recovery procedure – Making sure repair engineer can take proper action upon crash – Directly affects repair time, hence uptime. • Different error codes are linked back to root cause • Well described error linking idiom
24. Error Linking int queue_add(CCQU_queue *queue, void *item_data, bool front) { int r = OK; … if ((r == OK) && (queue == (CCQU_queue *) NULL)) { r = CCXA_PARAMETER_ERR; ERXA_LOG(r, 0); } … if (r == OK) { r = PLXAmem_malloc(sizeof(CCQU_queue_item), (void **) &qi); if (r != OK) { ERXA_LOG(r, 0); ERXA_LOG(CCXA_MEMORY_ERR, r); r = CCXA_MEMORY_ERR; } } if (r == OK) { ... } return r; } Initialization Root error Error logging Skipping Linking Propagation
25. 25 Error Linking Quality • Fault model: – Wrong error variable returned, – assigned and logged value mismatch, – not linked to previous value, – unsafe assignment, ... • Can be identified using analysis of program dependence graph • For each path find out whether error value is properly set, checked, logged and returned
26. 26 Static Analysis in SMELL State Machine for Error Linking and Logging
27. 27 Violation reports CodeSurfer File Browser Violations Browser
28. 28 SMELL 0.2 Initial Findings KLOC Reported Deviations False Positives Limitations Validated Deviations CC1 3 32 2 4 26 CC2 19 72 20 24 28 CC6 15 16 0 3 13 CC4 14.5 107 14 13 80 CC5 15 9 0 3 6 66.5 236 36 47 153 15% 20% ~2/Kloc
29. 29 Crosscutting Concerns: Status so far • Preliminary results • 30% of code devoted to boiler plate code • 3 deviations from idiom per KLOC – Just for parameter checking and error linking
30. 30 The ASML Weaver • ASML decided it would benefit from weaver • Developed in house weaver called Mirjam – Joint work with UT – Ideals “transfer project” • Written in Java • Integrated in ASML build process • Tracing concern for new code • Error linking presently too complex
31. 31 Envisioned Solution for the Error Linking Concern • Thinking with ASML about alternative macrosets – Avoid most likely faults as we identified them – Closer to “try-catch” mechanism – Consider relying on setjmp / longjmp – XXL C library? • Step 2: Further improvements using aspect weaving Work in Progress!
32. 32 The ASML Error Linking Checker • Our experiment conducted with prototype tool • Lack of scaleability, performance • Too many false positives • ASML initiated “transfer project” to develop and adopt production-ready checker (work in progress)
33. 33 Systematic Variations? Is the idioms-based implementation of a crosscutting concern sufficiently systematic such that it is suitable for an aspect-oriented solution? Calls for an analysis of idiom variability: • How can we determine this? • Distinguish essential from accidental variability? • What are the aspect design implications? • What are migration implications?
34. 34 Variability Analysis • Method for analyzing variability 1. Idiom definition 2. Idiom extraction 3. Variability modeling 4. Variability analysis 5. Interpretation of results • Application to cases – ASML tracing case – Open source precondition checking case
35. 35 Idiom Definition & Extraction 1. Obtain unambiguous definition – from manuals? – reconcile different interpretations from various developers 2. Extract idiom code from base code (untangling) • Recognize locations containing code • Obtain compilable representation of just the idiom • Use slicing (CodeSurfer) or program transformation tools (ASF+SDF) • Feasibility depends on complexity of the idiom
36. 36 Example ASML Concern: Tracing int CC1DA_scan_pending( int scan_id, CC1DA_scan_component scan_component, bool *scan_pending_p) { THXAtrace("CC1", THXA_TRACE_INT, func_name, "> (scan_id = %d;scan_component = %s)", scan_id, CC1DA_SCAN_COMPONENT_ENUM2STR(scan_component)); ... THXAtrace("CC1", THXA_TRACE_INT, func_name, "< (scan_pending = %b) = %R", *scan_pending_p, r); }
37. 37 Tracing Variability (Subset) int CC1DA_scan_pending( int scan_id, CC1DA_scan_component scan_component, bool *scan_pending_p) { THXAtrace("CC1", THXA_TRACE_INT, func_name, "> (scan_id = %d;scan_component = %s)", scan_id, CC1DA_SCAN_COMPONENT_ENUM2STR(scan_component)); ... THXAtrace("CC1", THXA_TRACE_INT, func_name, "< (scan_pending = %b) = %R", *scan_pending_p, r); } Macro Component Style Function Formatting Parameter Para conversion
38. 38 Variability Modeling for Tracing Focus on two types of variability in tracing: 1. Function Level Variability • Way in which tracing functionality is invoked • Varying properties: (1) Tracing macro name; (2) component name; (3) function name; (4) internal versus external tracing 2. Parameter-Level Variability • Different ways in which a parameter of given type is traced / converted in different functions and components.
39. 39 CC1 CC2 CC3 CC4 total LoC 29339 17848 31165 4985 83337 functions 161 134 174 68 537 parameters types 108 71 65 49 249 tracing macro’s 1 1 2 1 2 component names 2 3 1 2 6 function names 3 1 1 1 3 Components under Study:
40. 40 Extracted function-level variability information from code: set_ill_rema_and_wl : trace “CC1” INT func_name set_ill_rema_and_wl : trace “CC1” INT func_name get_grating_indices : trace CC INT f_name get_grating_indices : trace CC INT f_name CC_rq_PFNRM : trace “CC1” INT func_name CC_rq_PFNRM : trace CC INT func_name CC_request_ags_height : trace “CC1” INT func_name CC_request_ags_height : trace “CC1” INT func_name ... : ... ... ... ....
41. 41 Variability Analysis • Search for recurring patterns in extracted tables – Systematic variability that might be captured into an aspect • Apply formal concept analysis – Mathematical classification technique – Search for concepts: • maximal groups of functions • that share a maximal group of attributes – Display relations between concepts in lattice
42. 42 Abstraction Techniques • Relational Algebra for “lifting” – Relations: method calls method, class contains method – Lift to class level: class requires class Ø define: requires := contains ◦ calls ◦ contains-1 e.g. C1 contains mA C3 contains mC mA calls mB mC calls mD C2 contains mB C4 contains mD mA calls mC C1 contains mA, mA calls mB, mB contains-1 C2 → C1 requires C2 C1 contains mA, mA calls mC, mC contains-1 C3 → C1 requires C3 C3 contains mC, mC calls mD, mD contains-1 C4 → C3 requires C4 abstracted from 7 to 3 arrows!
43. 43 Æ P1 P2 P3 P4 Æ Sets of items Sets of features ┬ All Variables Abstraction Techniques (2) P1 P2 P3 P4 NAME x TITLE x INITIAL x PREFIX x NUMBER x NUMBER-EXT x ZIPCODE x STREET x x CITY x x (Mathematical) Concept Analysis – group items based on common features – find maximal subsets sharing same features – e.g. data that is used by modules Build lattice from all subset based on sharing ┬
44. 44 P1 P2 P3 P4 NAME x TITLE x INITIAL x PREFIX x NUMBER x NUMBER-EXT x ZIPCODE x STREET x x CITY x x Abstraction Techniques (2) Æ P1 P2 P3 P4 Æ P1 Name Title Initial Prefix P4 Number Nb-Ext Zipcode Street City (Mathematical) Concept Analysis – group items based on common features – find maximal subsets sharing same features – e.g. data that is used by modules ┬ All Variables ┬
45. 45 P1 P2 P3 P4 NAME x TITLE x INITIAL x PREFIX x NUMBER x NUMBER-EXT x ZIPCODE x STREET x x CITY x x Abstraction Techniques (2) Æ P4 P1 P2 P3 P4 Æ P1 Name Title Initial Prefix City P2 P4 P3 P4 Street Number Nb-Ext Zipcode Street City (Mathematical) Concept Analysis – group items based on common features – find maximal subsets sharing same features – e.g. data that is used by modules → first step to “OO redesign” ┬ All Variables ┬
46. 46 CC1 Function-Level Variability http://conexp.sf.net/
47. 47 CC2 Function-Level Variability
48. 48 CC3 Function-Level Variability
49. 49 Combined Lattice for CC1- CC4
50. 50 Function-Level Variability Key Results • In total 29 main tracing variants – Some variants shared across components (29<31). • Only 5.7% of the functions traced “by the book”.
51. 51 Parameter-Level / converter function variability • 46% (115) of the parameter types never traced • 16% (40) traced consistently • 15% (37) untraced as well as traced by one converter • 23% (57) traced through more than two different converter functions. 42%
52. 52 Parameter Type Conversion Variability • Most of the inconsistent types converted in two or three different ways only • Outliers: – bool traced in 11 ways – double traced in 13 ways Inconsistent use of typedefs + corresponding converters • Larger components tend to be less consistent • In some cases converter functions mixed up: – e.g., chuck_enum versus chuck_id_enum
53. 53 Precondition Checking Idiom in Open Source Gaim app
54. 54 Variability Modeling for Precondition Checking Three levels of variability 1. Parameter variability • Are all parameter types systematically checked • Are they compared to same value 2. Intra-procedural variability • Do all checks within same function return same default value 3. Inter-procedural variability • For functions of same return type, do precondition checks return the same default value?
55. int gboolean char* gaimchat* gaimbuddy*
56. 56 Aspect Design / Function-Level Variability • Best / most compact way of expressing tracing’s function level variability? – found 29 sensible combinations – do we need all? – metrics on most common ones • Aspect per combination, versus configuration mechanisms for individual properties per (set of) functions • Did not yet include input/output variability – Would require advice on in/out flavor.
57. 57 Aspect Design Parameters & Default values • Parameter-level variability – “Advice on parameter type” • Specific per function / annotations? – Tracing: indicate converter function – Precondition checking: indicate 1. whether parameter should be checked 2. with what expression it should be compared – Advice on data flow / call chains / “cflow” ? • Precondition checking default value – int / bool / char used in multiple ways: type inferencing
58. 58 Migration (I) • Variability analysis supports – Design of “target” aspect language – Potential migration path from legacy to target language • Migrations always painful, risky, and expensive • Migration should consider all variants found • Build migration tool support for common ones • Need to fix accidental variability / anomalies
59. 59 Migration (II) • Reduce risk by insisting having weaver regenerate original code? – The “zero-diff” policy – Poor use of aspect language – Complicates weaver significantly • Reduce risk by testing? – Crosscutting concern code typically not exercised in test suites.
60. 60 Variability Results Revisited • Further variability? – Results “lower bound” on the real amount of variability – E.g.: distinguish input and output in tracing, format string, typical position of trace code in function, ... – Studied only fraction of ASML code • Are these figures representative? – CC1-CC4 differ in size, age, and maintenance history – CC1-CC4 presently under rework – Variability higher than what developers had expected – We expect variability for other ASML concerns to be similar
61. 61 The Variability Analysis Method Revisited • Genericity: – Idiom definition, modeling, and interpretation manual – Tool configuration needed for other steps • Scalability – Fact extraction: ~ 2-3 minutes – Concept lattice creation: < 1 minute – Lattice can be large: focus analysis on concepts with own objects
62. 62 Conclusions • A method for analyzing idiom variability – Based on variability modeling & concept analysis • Used to analyze variability in – ASML Tracing – Gaim precondition checking • Results guide aspect design • Results facilitate migration impact analysis
63. 63 Points to Ponder • Are you using idioms? – With or without automated checking? • Are you relying on “systematic policies”? • Can you capture them in idioms? • Can we expect similar variability in other C systems? • What would the findings be for Java systems? • Do we need domain-specific aspect languages?
64. 64 Tracing Findings • Each component actually uses a mix of various styles • Just 6% of the functions uses the exact default idiom • 42% of the traced parameters converted to string in more than one way • Calls for dedicated aspect support such as advice for parameters depending on their type. – Advice for parameters depending on types, – Access to module name • Significantly complicates migration
65. 65 Conclusions • Crosscutting concerns are everywhere • Methods / tools to analyze variability and correctness • Idiomatic implications are fault-prone • Variability analysis supports aspect design and migration impact analysis
66. 66 More Information • M. Bruntink, A. van Deursen, and T. Tourwé. Isolating idiomatic crosscutting concerns. ICSM 2005. IEEE. • M. Bruntink, A. van Deursen, R. van Engelen and T. Tourwé. On the use of clone detection for identifying crosscutting concern code. IEEE Tr. Sw. Eng., 2005. • M. Bruntink, A. van Deursen and T. Tourwé. Discovering Faults in Idiom-Based Exception Handling. ICSE 2006, ACM/IEEE. • M. Bruntink, A. van Deursen, M. d’Hondt, and T. Tourwé. Simple crosscutting concerns are not so simple. A method for determining variability in idiom-based implementations. AOSD, ACM, 2007