I ' LlBRARy M'Chigan State 1% PLACE IN RETURN Box to remove this checkout from your record. TO AVOID FINES return on or before date due. MAY BE RECALLED with earlier due date if requested. DATE DUE DATE DUE DATE DUE 6/01 c:/CIRC/DateDue.p65-p.15 {mam or O' E"DU,\\' .‘o‘ to. L-_ A ENABLING INTEGRATIVE ANALYSES AND REFINEMENT OF OBJECT—ORIENTED MODELS WITH SPECIAL EMPHASIS ON HIGH-ASSURANCE EMBEDDED SYSTEMS By Laura Anne Campbell A DISSERTATION Submitted to Michigan State University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Department of Computer Science and Engineering 2004 9" b ‘ . o" s 5 c y . , ‘ . - . . . . h - . ‘ 4 . . o \, .. ' 0 N o ' \ - . ‘ . a . I h A - o o.. ..‘ 1 a . . ‘ \ - v . (v t ‘ ' ~ I.. ‘\ -a A ‘ \ a. K, K __ . r. N‘. ~a. . A . . 6 .. ~ \ . ‘ u. . . .’ \ ' I \ _» ., ‘. . A v . ‘C p e. h.‘ n. v . I ‘v . Av \ \ u ABSTRACT ENABLING INTEGRATIVE ANALYSES AND REFINEMENT OF OBJECT-ORIENTED MODELS WITH SPECIAL EMPHASIS ON HIGH-ASSURANCE EMBEDDED SYSTEMS By Laura Anne Campbell Requirements modeling and analysis is one of the most difficult tasks in the soft- ware development process. Hardware constraints and potentially complex control logic exacerbate this problem for embedded systems development. While require- mentS errors can be costly for software systems in general, they can be especially costly for high-assurance or safety-critical embedded systems where failure can have dire consequences. Therefore, methods for modeling and rigorously analyzing embed- ded systems requirements have value for developers. The ad hoc development approaches currently used in embedded systems lack sys- tematic methods for both modeling and analyzing requirements. Although the em- bedded systems community has expressed interest in exploring how Object-oriented modeling, specifically the UML, can be used for embedded systems development, UML lacks a formal semantics, thus precluding rigorous analysis of requirements ex- pressed as UML models. While formalization of UML enables rigorous analysis of formal models derived from UML diagrams, formalization itself is not sufficient to broaden the community of embedded systems developers who can use formal meth- ods to rigorously analyze requirements. To enable developers to model and analyze requirements in UML without having to know details of formal models requires a framework and process that takes advantage of a UML formalization yet insulates developers from the formal models produced by such a formalization. This research presents an approach to validating embedded systems requirements modeled as both UML diagrams and LTL properties using formal verification (6.9., model checking) techniques. We describe a model development and analysis frame— work that insulates the developer from formal models and outputs of tools, and an overall model development and analysis process. © Copyright by LAURA ANNE CAMPBELL 2004 TO Mother “Never was there a better daughter, kinder sister, or truer friend.” — Jane Austen, Emma ACKNOWLEDGMENTS It is not possible in this Space to list every person who assisted me along this journey, but I especially wish to thank my committee members: Dr. Betty H. C. Cheng (chairperson), Dr. R. E. Kurt Stirewalt (CO-advisor), Dr. Anthony VVojcik, and Dr. Bryan Pijanowski for their time and guidance, and constructive comments. Without their support and encouragement, this work would not have been possible. I would also like to thank Dr. Abdol-Hossein Esfahanian, Dr. Eric Torng, and Graduate Secretary Linda Moore for providing a listening ear when I needed it. In many ways this work has been a synthesis of previous explorations integrating informal and formal methods. I especially wish to thank the following people from the Software Engineering and Network Systems (SENS) research group at Michigan State University: Dr. Y. Enoch Wang (OMT-to—LOTOS formalization), Dr. William E. MCUmber (UML-to—Promela formalization and general formalization framework), Min Deng (rewriting Hydra to use the Visitor design pattern), Sascha Konrad (re- quirements patterns), Ali Ebnenasir (domain knowledge of fault-tolerance), and Ryan Stephenson (coding contributions on MINERVA and Hydra). This work has been supported in part by the following grants: NSF EIA- 0000433, BIA-0130724, CDA-9700732, CDA-9617310, COR-9633391, CCR-9901017, CCR-9984727; DARPA grant No. F30602-96-1-0298, managed by Air Force’s Rome Laboratories; Department Of the Navy, and Office of Naval Research under Grant No. N00014—01-1-0744; a Motorola doctoral fellowship; and in cooperation with Eaton Corporation, Siemens Automotive, and Detroit Diesel Corporation. Finally, I must thank my husband Paul, family, and friends who were there for me throughout this process. Thank you. vi !\ LIST OF Fll l lntrtniurt c I r‘ P‘- _ . a. A. o .9. ‘ 7“ b‘ ‘ -o s . l ,’V 4 ' v.- .‘ ‘ I I l l°- . g " ....A, ‘ “' ‘.‘p-v- 0.. ‘2‘ ..l ‘.‘i ' -V~ II I' o.. L._ ‘ '1“ ‘ V ..‘) -.<..‘l‘ 'zo‘ P ..3 r... ".n H (i b v. .. ‘ >« g l O‘ A . .. (1..., ‘ O- . “a h"! 9.- . l “L.. -‘\ , d ...J Oji '_ Q. ‘ o ". I ‘ . .“ u ‘. ‘ '1‘ . ‘. . 7‘ E.) t... a _.‘ 7v . k . lt.~| D . - - N._ 5.. ' | .J , ~‘ 4‘ ‘ .A,‘. '\ ." a. , , V 'A 7-. . I i .I- . ..; -. ‘ -'\ ., , ‘ «.J 4, ' "N. \ . .‘ . i r C . ~’\\ r Y I.‘ L. :3 Anall'Sm . ‘$ ‘ D . A ~“ .41. ,3 h. a‘ ’J. o “.‘ o‘ t .‘ . ‘s I", ‘ l D t ' . 1‘ ‘ ‘ | ‘ . 1 h . ‘J 9‘" ‘ . I. A . " ‘ I . r .L .~ u LI" p.“ ' ' .. v . w , . J V —‘ - \ « \.' .- ”"4, D ' ...‘ . ' ‘ ‘ g I TABLE OF CONTENTS LIST OF FIGURES 1 Introduction 1.1 Problem Description ............................. 1.2 Thesis ..................................... 1.3 Contributions ................................. 1.4 Organization of Dissertation ......................... 2 Background 2.1 Formalization of OMT ............................ 2.1.1 OMT Overview ............................... 2.1.2 LOTOS Overview ............................. 2.1.3 Analysis Tools for LOTOS ......................... 2.1.4 Formalization Overview .......................... 2.2 Formalization of UML ............................ 2.2.1 General Formalization Framework ..................... 2.2.2 UML Overview ............................... 2.2.3 Promela and LTL Overview ........................ 2.2.4 Analysis Tools for Promela ........................ 2.2.5 Formalization Overview .......................... 3 Preliminary Investigations: Highlights and Lessons Learned 3.1 Highlights ................................... 3.1.1 Analysis Process .............................. 3.1.2 Integrative Analyses ............................ 3.1.3 Analysis Tool Output ........................... 3.2 Lessons Learned ................................ 4 Model Development and Analysis: Framework and Process 5 Analyses 5.1 Structural Analyses .............................. 5.1.1 Preventing or Containing Diagram Errors ................ 5.1.2 Problems Within a Diagram ........................ 5.1.3 Problems Between Diagrams ........................ 5.2 Behavioral Analyses ............................. 5.2.1 Simulation ................................. 5.2.2 Model Checking .............................. vii 49 59 61 62 66 66 74 6 Visualiz: .- ’ “ ~- '1. ' I- .. -U‘ ' ta“, \.. . o- “‘ “ . .r A x ‘ ‘. r \. . . - ~ « ‘ . ~ ~ P~ . l i . J 'c . . A 'x I ’ .‘ ¢ r . 4 u .- A . ' 1..- ‘ -‘ :v.I‘ .- ‘2 ~ . .‘.. ‘ ' ' “‘ A. .. F . h. ~ . ‘ U"... 4 . V N '0 "’ . ""-~.. '- '1 \r Q -. ~n . . ‘0 n’.. . ‘f a) ' .. .‘ .1 1 " ‘ ‘ ‘1 . 'n . , 1i P- .J ‘5’" _ ‘ I k 1 9-. "1 I o \ ‘ ‘ .. . . l . A. .‘ J [ ' \ . .I‘ ‘ . c 1" 0“ "c I,.,' k.‘ .. ° . Q '.\ ‘ f . ~ . ‘ ! .~. ~ ' ! .‘ , a O .. ‘ . .- ' . ‘A In -‘ g. It .- - J. n . ‘ v ' I . VI c A n, ‘, g . r ' ‘ ‘ l . ‘ l" .: .5 .; .t‘ I ' . -.‘| Y t ‘ 3 .-| ' . "‘-i--. - ,c( f \ ~ ‘ .t L 4" . ' '.. 0. u I 6 Visualizations 76 6.1 Producer- Consumer Example ........................ 78 6.2 Structural Visualizations ........................... 81 6.2.1 Within and Between Diagrams ...................... 81 6.2.2 Structural Analyses Applied to the Producer- Consumer Example, with Visualizations ........................... 81 6.3 Behavioral Visualizations ........................... 88 6.3.1 State Diagram Animation ......................... 89 6.3.2 Sequence Diagram Generation ....................... 92 6.3.3 Collaboration Diagram Generation and Animation ........... 95 6.3.4 Behavioral Analyses Applied to the Producer—Consumer“ Example, with Visualizations ........................... 98 7 Validation: Industrial Case Study 109 7.1 Adaptive Cruise Control Project Overview .................. 109 7.2 UML Modeling for Case Study ....................... 112 7.3 Structural Analysis .............................. 118 7.4 Behavioral Analysis .............................. 119 7.4.1 Simulation of Preliminary UML Diagrams ................ 120 7.4.2 Model Checking Initial UML Diagrams ................. 122 7.4.3 Model Checking After Changing Default Conditions ........... 124 7.4.4 Model Checking New Driving Scenarios ................. 125 8 Reflection: Cost and Applicability 129 8.1 Cost of Instrumentation ........................... 129 8.1.1 Overview .................................. 130 8.1.2 Defining Cost ................................ 135 8.1.3 Producer— Consumer Example ....................... 136 8.1.4 Cost of Instrumentation as Applied to Adaptive Cruise Control ..... 149 8.1.5 Conclusions ................................. 155 8.2 Applicability of the Approach to Other Domains .............. 160 9 Extension: A Pattern-Driven Approach to Fault Handling 162 9.1 Detectors and Correctors ........................... 164 9.2 Object Analysis Patterns and Constraints ................. 170 9.2.1 Object-Analysis—Pattern-Driven Modeling and Analysis ......... 173 9.3 Fault Handler Requirements Pattern .................... 175 9.3.1 UML Modeling and Semantics for the FaultHandler ........... 177 9.4 Refined UML Modeling, Semantics, and Formalization for the FaultHandler 181 9.5 Adaptive Cruise Control Example ....................... 190 9.5.1 Fault Handling in Adaptive Cruise Control ................. 192 10 Literature Review 199 10.1 Guidance for Model Construction ...................... 200 10.1.1 Graphical Editing Environments ..................... 203 . " E . . . x T? .. . .- . .J ‘ ' . 'V ‘ u v . . y, .n. . ' ‘ . \ ‘ - , . a -’- - ‘ . ‘\{ V‘ . . . ~> - . ~ ,. l'. . 0 -~ . " 5 . a v .. . ‘. ... I C V‘ l o m ’ . u I. _v l n o . . ' ~ ~ _, \. I I s . o - v c | " a. 4 ° - .s. . ‘ I. O9 . . ‘ d‘ v . ' l I ' . u. a L“ ' I- w- . . . .._¢ I C(.'n(:1 ‘. | |\ 'e‘ \ . o.‘ *~ «I ..... " .- A n o.. ' p -“ IA. I YV. .I \ Q .. ' ‘~. ‘ " v. ‘Q .Q P. s K. a L g" U‘V K . ‘ .‘ "~ ‘ r I. C I‘ n v-1 . . v p ‘- . Q .. -. _ ‘. v 10.1.2 Stereotypes ................................. 205 10.1.3 Patterns ................................... 207 10.2 Guidance for Instantiating Formal Properties ............... 210 10.3 Model Analysis ................................ 211 10.3.1 Diagram Consistency Checking ...................... 211 10.3.2 Behavioral Analysis of UML Diagrams with Spin ............ 212 10.4 Visual Interpretation of Analysis Results .................. 213 10.5 Development Environments for Embedded Systems ............ 214 10.5.1 Omega Project ............................... 215 10.5.2 SCR* .................................... 217 10.5.3 NIMBUS ................................... 218 10.5.4 ARTiSAN’S Real—time Studio ....................... 218 10.5.5 IBM Rational’s Rose RealTime ...................... 219 10.5.6 I-Logix’s Rhapsody ............................. 219 10.5.7 Telelogic’s TAU Generation2 ....................... 220 11 Conclusions and Future Investigations 221 11.1 Summary of Contributions .......................... 223 11.2 Future Investigations ............................. 226 APPENDICES 233 A Wang’s Design Process 234 B TRMCS Refinement 236 C Formal Model Generator Architectures 244 CI Wang’s Approach ............................... 244 C2 McUmber’S Approach ............................ 246 D Adaptive Cruise Control Attributes and Signals 248 E Adaptive Cruise Control Control State Diagram 254 F Hydra-Generated Promela Code for Adaptive Cruise Control 257 G Hydra-Generated Promela Code for Producer- Consumer 266 G.1 Baseline .................................... 266 G2 UML States .................................. 272 G3 UML Transitions ............................... 278 G.4 Both UML States and UML Transitions .................. 285 H Producer-Consumer Spin Analysis Results 294 I Original Fault Handler Requirements Pattern 299 1.1 Fault Handler: Behavioral Pattern ..................... 299 ix BIBLIOGI BIBLIOGRAPHY 311 v a ~_ . D . ~ . i o . . '. .. - 8.... -.... '— 5" . . Lo; 'q-u~ .- ..I . - ....L.... , . _ - — o I - ‘ uni. ‘ v-\ ' .‘ \ o L.A M n R v... c ' a . l. v: Q. ‘ l-. l - . ~\ LA‘ ' I» . 1- . ~ s..- ,_H r, h._‘ . 5 r', \. o C ‘ ’ . . N \V v. lM - A..‘- 'u a a“. ' x. 1“. ‘1. U. ¢:”\ l. . I“ I. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 LIST OF FIGURES Example OMT class diagram ........................ Example OMT state transition diagram .................. Example OMT data flow diagram ...................... LOTOS synchronization with data exchange ................ LOTOS model of recursive soda vending machine ............. LTS of recursive soda vending machine ................... Overview of OMT-to-LOTOS formalization rules ............. Unconstrained mapping from semi-formal to formal model ........ Constrained mapping from semi-formal to formal model ......... Example UML sequence diagram ...................... Example UML collaboration diagram .................... Overview of UML-to—Promela formalization rules ............. Analysis process for LOTOS models derived from OMT diagrams . . . . System-level object model of the TRMCS .................. System-level Object functional model of the TRMCS ............ System-level dynamic model of the TRMCS ................ High-level LOTOS model of the TRMCS, data part ............ High-level LOTOS model of the TRMCS, behavior part .......... Test for high-level TRMCS model ...................... Results Of high-level TRMCS model under test ............... Information about refined TRMCS model under test ............ xi 13 15 15 16 18 20 20 22 23 26 30 32 33 33 34 35 36 37 38 3.10 Example of Shortest path to state 120 in refined TRMCS model under test 3.11 Pattern: undefined patient records in response to valid queries ...... 3.12 Failure on second query (DETROIT) in refined TRMCS model under test . 3.13 Original TRMCS model under test ...................... 3.14 Refined TRMCS model under test, safety-reduced ............. 3.15 TOPO/LOLA log file indicating deadlock in ENFORMS .......... 3.16 Inconsistent OMT state diagrams ...................... 3.17 LOTOS model fragments from inconsistent diagrams ........... 4.1 Suggested architecture for a formal model generator ............ 4.2 Model development and analysis framework ................ 4.3 Framework from Figure 4.2 instantiated with tools ............ 4.4 Iterative and incremental model development and analysis process . . . . 5.1 Iterative and incremental model development and analysis process, reprised from Figure 4.4. Bold boxes (A, B, D) represent structural analyses; dash-dotted boxes (F, G, H) represent behavioral analyses. . 5.2 Syntactically incorrect state diagram, with respect to graphical syntax 5.3 Syntactically correct state diagram, with respect to graphical syntax 5.4 Nonsensical transition label ......................... 5.5 Structured nonsense on a transition ..................... 5.6 Overall class diagram well-formedness assumptions ............ 5.7 Class diagram parts well-formedness assumptions ............. 5.8 Overall state diagram well-formedness assumptions ............ 5.9 Integration assumptions between class and state diagrams ........ 5.10 Problems between Class and state diagrams ................. 5.11 Problems among state diagrams ....................... xii 39 40 40 42 43 45 47 47 51 53 55 57 60 63 63 66 67 68 69 72 73 t“ . 1 ,. . . . N \' .‘ . s ., . G.‘_ ‘ i 'Y -L 7 . . i. . ' A. I, ‘ n '1‘ o '«M ' ‘ fi ‘ . A ‘ ‘ «I g g. A. F» :J' ~:.. \( is.... “ F. u “‘6' 'Q .h ;.~ .. .‘N ‘ ..~h ‘ .‘ 4‘. § ‘5 6.1 Iterative and incremental model development and analysis process, reprised from Figure 4.4. Bold arcs 1-4 represent feedback of anal- ysis results to diagrams. ......................... 6.2 UML class diagram for Producer- Consumer model ............. 6.3 UML state diagram for Producer ....................... 6.4 UML state diagram for Consumer ...................... 6.5 Structural problems reported by Hydra ................... 6.6 UML state diagram for Producer showing highlighted transition from state Waitingj‘orjemand to state Advertise that uses the undeclared at- tribute num ................................ 6.7 UML class diagram for Producer-Consumer model Showing highlighted class Producer that has not declared the attribute num nor the signal request ................................... 6.8 UML state diagram for Producer after fixing structural problems. (Used declared attribute numnade instead of undeclared num on transition from state Waiting_For_Demand to state Advertise.) ......... 6.9 UML state diagram for Consumer showing highlighted transition from state HaveJloneleilLSpend to state Waiting_For_Supp1y that uses the undeclared Signal request ......................... 6.10 UML state diagram for Consumer after fixing structural problems. (Used declared Signal demand instead of undeclared request on transition from state Have_Money_Will-Spend to state Waiting-For-Supply. Added initial transition to state Have_Money_Will_Spend.) .......... 6.11 UML Class diagram for Producer- Consumer model after fixing structural problems. (No changes were made.) ................... 6.12 Raw trace data output from Spin with no flags .............. 6.13 Trace data from Spin processed into human-oriented report ........ 6.14 Ttace data from Spin processed into visualization instructions for MIN- ERVA corresponding to lines 19—24 of Figure 6.13 ............ 6.15 Highlighted transition corresponding to lines 19—20 of Figure 6.13. Pro- ducer transitions from state Waiting_For_Demand to state Advertise on event demand. ............................. 6.16 Highlighted state corresponding to line 21 of Figure 6.13. Producer enters state Advertise. ............................. 79 80 80 82 83 83 84 85 87 90 91 92 93 . ‘ '— _. . l 8.... ' a .— ‘v- . V g..- -.... "\ r? . . ‘ ‘ ~. .A. a O. . . ‘ a ‘4” J". .‘. v. \'V . ‘-'-‘. \ ' t r L . ‘v a.. . o \ .. -‘o. .- "3»: w. Irv . x,‘ ‘t. . F- I .5 o . .1 O '0 x “-1 ~.“ .‘ ‘ O .. I v I I . v. ,‘rv I . 5‘s.“ - . v I ‘ I . ‘. . l . ‘ .“\‘ 's 7. \ l "T x , . O ‘9‘ ,- VI, . I '. ‘\, .1 .. I ‘C - O o l‘rv . ll ‘ ‘k‘ e . a 6.17 6.18 6.19 6.20 6.21 6.22 6.23 6.24 6.25 6.26 6.27 6.28 6.29 6.30 Highlighted transition corresponding to lines 22—23 of Figure 6.13 Producer transitions from state Advertise to state Wait ing_For_Demand on the implicit event done ............................. Highlighted state corresponding to line 24 of Figure 6.13 Producer enters state Waiting_For-Demand ......................... Example sequence diagram corresponding to events depicted in Figure 6.13 (page 91) ................................. Visualization commands processed from raw trace data output from Spin with verbose flags ............................. Example collaboration diagram corresponding to line 28 in Figure 6.20 UML state diagram for Producer after fixing structural problems, repeated from Figure 6.8. (Used declared attribute num.made instead of un- declared num on transition from state Waiting_For_Demand to state Advertise) ................................ UML state diagram for Consumer after fixing structural problems, re- peated from Figure 6.10. (Used declared signal demand instead of undeclared request on transition from state Have_Money_Will_Spend to state Waiting-For_Supply. Added initial transition to state HavefloneyfiilLSpend.) ........................ UML Class diagram for Producer- Consumer example after fixing structural problems, repeated from Figure 6.11. (No changes were needed.) . . . Human-oriented report for Producer-Consumer example generated from the output of a Spin simulation with verbose flags ........... Sequence diagram for Producer-Consumer example generated from the output of a Spin Simulation with verbose flags ............. UML class diagram for Producer—Consumer example after fixing behav- ioral problems. (Added attribute editionmum and Signal supply to class Consumer.) .............................. UML state diagram for Producer after fixing behavioral problems. (Added message supply sent to Consumer on transition from state Advertise to state Waiting_For_Demand.) ...................... UML state diagram for Consumer after fixing behavioral problems. (Added event supply on transition from state Waiting-For-Supply to state Have_Money-Will-Spend.) ........................ Trace data from Spin processed into human—oriented report ........ xiv 94 94 96 97 98 99 99 100 102 103 104 104 107 ‘ H . ,P. l " q -,. ~ ‘. . . . . _ . i. _. . . . \'. . - . . .. \. . ' . \y o I r- \. .' . C . .. \f ~ F a , . - - . . . .v u . .. .. p. s‘ r‘ , ‘ - . l" ‘ w, '\\ ' x \’ - . \ o N \' . o ‘ . . .. .. v . ~ \. . ' . t'v . ‘ ~~.. ' \. h 5‘ . . ,... D \0 y... 5“ .. .,.‘ b ‘0 h v- .7 -. ‘ ._ | o -- \ 7‘ t'. “A. . \. P‘. l’ ‘ . ‘1‘. o ‘o \. \ . ~ h” .. v . t-‘C , ., ‘ (9' \l \s (_ \' I y. 6.31 7.1 7.2 7.3 7.4 7.5 7.6 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 Sequence diagram corresponding to events depicted in Figure 6.30 . . . . 108 Common Situations the Adaptive Cruise Control system must handle. . . . 111 Class diagram for Adaptive Cruise Control .................. 114 State diagram for Adaptive Cruise Control class Car ............. 115 State diagram for Adaptive Cruise Control class Radar ........... 116 Sequence diagram from simulation. ..................... 121 Sequence diagram representing counterexample. .............. 128 Model development and analysis framework encompassing formalization framework (reprised from Figure 4.1 in Chapter 4) ........... 131 Portion of integrated frameworks from Figure 8.1 examined in this section 132 Class diagram for Producer-Consumer ................... 137 State diagram for Producer- Consumer class -SYSTEMCLASS- ...... 138 State diagram for Producer— Consumer class Producer ........... 138 State diagram for Producer- Consumer class Consumer ........... 139 Finite state machine for .SYSTEMCLASS- proctype, baseline ...... 141 Finite state machine for Producer proctype, baseline ........... 142 Finite state machine for Consumer proctype, baseline ........... 143 Finite state machine for .SYSTEMCLASS- proctype, option Both . . . . 144 Finite state machine for Producer proctype, option Both ........ 145 Finite state machine for Consumer proctype, option Both ........ 146 Number of unique (Promela) states in formal model of Producer- Consumer example for baseline and each breadcrumb option ........... 148 Cost: Change in number Of unique (Promela) states in formal model of Producer— Consumer example for each breadcrumb option ....... 149 Number of unique (Promela) states in formal model of Adaptive Cruise Control for sunny-day and rainy-day scenarios ............. 151 Cost: Change in number of unique (Promela) states in formal model of Adaptive Cruise Control for sunny-day and rainy-day scenarios ..... 152 XV 8.17 8.18 8.19 8.20 8.21 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 Number of unique (Promela) states in formal model of Adaptive Cruise Control for Properties 1 — 4 checked against sunny-day scenario . . . . Cost: Change in number of unique (Promela) states in formal model of Adaptive Cruise Control for Properties 1—4 checked against sunny-day scenario .................................. Number of unique (Promela) states in formal model of Adaptive Cruise Control for Properties 4 — 6 checked against rainy-day scenario . . . . Cost: Change in number of unique (Promela) states in formal model of Adaptive Cruise Control for Properties 4 — 6 checked against rainy-day scenario .................................. Cost versus state Space Size per breadcrumb option ............ Modeling detectors and correctors in the UML class diagram ....... Pattern 1 for modeling detectors and correctors .............. Pattern 2 for modeling detectors and correctors .............. Pattern 3 for modeling detectors and correctors ' .............. Current list of object analysis patterns for embedded systems [1] ..... Using Object analysis patterns and constraints to drive the model devel- opment and analysis process ....................... UML class diagram template from the original Fault Handler requirements pattern incorporating a FaultHandler into an embedded system . . . . UML state diagram template for the ComputingComponent from the orig- 153 154 156 157 158 166 167 169 171 172 174 176 inal Fault Handler requirements pattern, including “safe” states [2, 3, 4] 178 Sample UML state diagram template for a centralized FaultHandler (not included in the original Fault Handler requirements pattern) utilizing Detector-Corrector Pattern 3 ....................... Refined UML class diagram template for FaultHandler utilizing Detector- Corrector Pattern 3 ............................ Spin non-deterministically interleaves all processes (dashed lines), each representing the behavior of a UML class. ............... Refined UML class diagram template for FaultHandler utilizing Detector- Corrector Patterns 2 and 3 ........................ Refined UML state diagram template for FaultHandler utilizing Detector- Corrector Patterns 2 and 3 ........................ xvi 179 180 183 184 .‘ '— - v ‘ r '. ,..- ,. ‘ ‘. ' . u on ‘ n v .. r‘, ; v . - . .v I" . ' 5. _. l . O .,,. AN . r - to. “U -- -— ' p. « o J P ’— D ._ .x -. . V" I . . . . . .- p. . ,- s. . - . . A b‘ I. u to a. - A. -. ,. o—W _ .4 \ u: . . , - a. or -, I . ‘ o .4 db ' ~ 7". _ ' ’- 4 4 s. .‘ V l ' 0v 5.... . . g ' I s . o a: . F I l ‘ ‘ . ‘ t. . VG- ‘ . .A , A. ‘. 1' N' v- 1 “I...“ ' ~ -‘ I\ ‘ I ‘ .‘I DA. . 7|. s J u 8. - . .4 .‘ t. L. ‘.A'¢ . . .-. ‘ . O . \ ‘. u ' . ~o l1 .' r -. v x." \)-\ ' ( p r4 ' . I .,.~ i ‘ ‘ . .. A. ‘ I . _ - r n. _‘ x 4‘ . r. . .‘v “_' ..'I ‘r ~ ‘5 ‘l A ‘.' . . b o .. I r . . .0 . . 1 . -. Au, _‘, ‘.o ‘- . “I a n I“ r ‘ u ‘ .“ v. A... ' A , 4 . Q 1‘. ‘I'. l h t” I X a ,y o I‘- 4 .. i . “CaD‘ P. .L") . 9.14 9.15 9.16 9.17 9.18 9.19 9.20 9.21 9.22 9.23 Forcing Spin to interleave the behavior of the FaultHandler with the be- havior of the rest of the system. Spin alternates between allowing the FaultHandler to take a step (solid line) and allowing one of many Promela processes, each representing the behavior of a UML class, to take a step (dashed lines). ........................ Rule for increasing the scheduling priority of the FaultHandler: non- FaultHandler components may only take a step when (globaLUMLStep == 1) ................................... Rule for increasing the scheduling priority of the FaultHandler: after every UML step, enable the FaultHandler to take a step ........... Rule for increasing the scheduling priority of the FaultHandler: the Fault- Handler may only take a step when (globaLUMLStep == 0) ..... Rule for increasing the scheduling priority of the FaultHandler: after every FaultHandler step, enable the rest of the model to take a step ..... Elided Control state diagram. Control periodically enters state sendwarn (shown as a bold rounded rectangle). Portions of the state diagram that have been abstracted for illustrative purposes are shown with dashed states and transitions (dashed rounded rectangles and directed arcs, respectively). Notes indicating critical conditions in the model are shown as shadowed callout boxes. .................. Refinements to Control class: Added boolean attributes alarm and sound. Refinements to Control state diagram: Added entry action “alarm := 1” to state sendwarn (both the action and the state are bold). Portions of the state diagram that have been abstracted for illustrative pur- poses are shown with dashed states and transitions (dashed rounded rectangles and directed arcs, respectively). Notes indicating critical conditions in the model are shown as shadowed callout boxes. Injecting a fault into the Adaptive Cruise Control model: Added non- deterministic self—transition with action “sound := O” to state warn in the Control state diagram to indicate that the alarm’s speaker fails (both the action and the transition are bold). Portions of the state diagram that have been abstracted for illustrative purposes are shown with dashed states and transitions (dashed rounded rectangles and di- rected arcs, respectively). Notes indicating critical conditions in the model are shown as shadowed callout boxes. .............. Adaptive Cruise Control FaultHandler class utilizing Detector-Corrector Pat- tern 2 ................................... 185 186 187 188 189 191 192 193 195 9F» '- I v. o» 3 Pk .4- av IA. $4.. ‘ u ,4.. o. \ u v .G v. Fri .” L.“ . <- ...A... a . . . .. . PH... all. .1 c 1. u ‘A . _ o .. 3 .13 .3 a q... PH 9.24 Adaptive Cruise Control FaultHandler state diagram utilizing Detector- Corrector Pattern 2 ............................ 196 9.25 Refinements to Control class to handle new signal shutdown from FaultHandler197 9.26 Refinements to Control state diagram to handle new signal shutdown from FaultHandler ................................ 197 9.27 Spin results for analyzing property 9 .................... 198 10.1 Model development and analysis framework ................ 201 10.2 Framework from Figure 10.1 instantiated with tools ............ 202 11.1 Example CTL property not fully expressible in LTL [5] .......... 228 A.1 Wang’s iterative design process ....................... 235 B.1 Refined TRMCS object model (attributes have been elided) ........ 237 B2 Refined TRMCS high-level dynamic model (state diagram) ........ 239 B3 Dynamic model (state diagram) of the TRMCS Client ........... 240 B4 Dynamic model (state diagram) of the TRMCS Name Monitor ...... 241 B5 Dynamic model (state diagram) of the TRMCS Channel .......... 241 36 Dynamic model (state diagram) of first TRMCS Data Repository ..... 242 B7 Dynamic model (state diagram) of second TRMCS Data Repository . . . . 243 B8 TRMCS LOTOS instantiations ........................ 243 CI Architecture for formal model generator realized in Wang’s approach . . 245 C.2 Architecture for formal model generator realized in McUmber’s approach 247 D.1 Variables and zones used by Adaptive Cruise Control Control algorithm. . 248 D2 Car attributes ................................. 250 D.3 Car signals ................................... 250 D4 Radar attributes ................................ 251 D5 Radar signals ................................. 251 F") ' A¢ 0. to Y? ‘A V . 1 — u ' . H - a. A ‘ ‘0 .o._ . A - u.‘n. a.. o x \‘ v ‘ . x. ... ... .. \’ v . 1.. .-. . i" v- 1 I i. '-a._. ‘ \ \., , K ¢ .. . Y" ’T n o ---.L. - 9 V'o D6 D7 El E2 H.1 H2 H3 H.4 I.1 I.2 I.3 Control attributes ............................... Control signals ................................. Legend for transitions in Figure E.2 ..................... State diagram for the Adaptive Cruise Control class Control ........ Spin analysis results for Producer— Consumer, baseline ........... Spin analysis results for Producer-Consumer, breadcrumb option UML States ................................... Spin analysis results for Producer-Consumer, breadcrumb option UML Transitions ................................ Spin analysis results for Producer-Consumer, breadcrumb option Both UML States and UML Transitions ................. UML use-case diagram for the Fault Handler Pattern ........... Structural Diagram for the Fault Handler Pattern ............. UML state diagram of the ComputingComponent in the Fault Handler Pat- tern .................................... xix 252 253 255 295 296 297 298 301 304 Chapter 1 Introduction As software has become increasingly used in critical systems where failure can have dire or even catastrophic consequences [6], the need to have high assurance in its correctness has increased. Many approaches to software development include at least the following two phases early in the software life cycle: requirements analysis (what the software will do) and design (how the software will accomplish its tasks) [7, 8]. Studies have shown that requirements errors are between 10 and 100 times more costly to correct at later phases of the software life cycle than at the requirements analysis phase itself [9]. Thus, requirements errors can have a significant impact on the reliability, cost, and safety of a system. One approach to this problem is to document software requirements and design us- ing a formal language, a language with a rigorously defined syntax and semantics [10]. This approach is one of the basic elements of the software engineering disciplines re— ferred to as formal methods, which are characterized by a formal language and a set of rules governing the manipulation of expressions in that language [10]. The advantages to using formal methods are significant, including the use of notations that are precise, verifiable, and facilitate automated processing. A formal model, a formal-language representation of a software system’s requirements and design, can 1 be rigorously manipulated to allow a developer to assess the consistency, complete- ness, and robustness of a design before it is implemented. However, attempting to construct a formal model directly from an informal, high-level (6.9., prose) require- ments document can be challenging. Additionally, formal methods by their nature are rigorous and many require a steep learning curve. Thus far, formal methods are not widely used in industry except for extremely critical software [11]. Other approaches to requirements analysis and design include numerous object— oriented techniques [12, 13, 14, 15]. These semi-formal methods enable the rapid con- struction of a system model using intuitive graphical notations with well-defined syn- tax, and user-friendly languages, including Object Modeling Technique (OMT) [14] and Unified Modeling Language (UML) [16, 17, 18]. While such techniques have proved to be useful, as measured by their popularity in industry [19, 20], the graphi- cal notations used with these methods are often (semantically) ambiguous, resulting in diagrams that are easily misinterpreted. The lack of formal semantics for the diagrams or their integration prevents rigorous and/ or automated analysis of them. Further- more, without rigorous development processes, users can potentially create diagrams that contain inconsistencies, ambiguities, and other types of errors that cannot be detected by syntax-oriented editing or analysis utilities [19, 21]. The potential result is a collection of erroneous diagrams that are used to guide the development of a computer-based system. In an effort to leverage the benefits and address the shortcomings of both formal and semi-formal approaches to requirements analysis and design, many projects [22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35] have proposed techniques for associating formal semantics with semi-formal modeling notations, including UML [26, 28, 29, 30, 31, 32, 33, 35]. The interest in UML is largely due to the fact that it has become a de facto standard in object-oriented software modeling and development. 2 1. 1 Problem Description Errors introduced during the analysis process are commonly the most expensive to fix, as they usually require subsequent changes to design and code [36]. While re- quirements errors can be costly for software systems in general [9], they can be es- pecially costly for embedded systems, i.e., systems with embedded microprocessors, not only for safety reasons but also in terms of hardware fabrication costs. Given the potentially critical nature of embedded systems (e.g., X-by-wire, medical devices, etc.) in which faulty behavior of a system could lead to significant loss, methods for modeling and developing embedded systems and rigorously analyzing behavior before starting the design phase and committing to code are increasingly important. However, currently much of the embedded systems industry uses ad hoc development approaches [37, 38] that lack systematic methods for both modeling and analyzing requirements, thus potentially leading to unreliable and unsafe systems. Although the embedded systems community has expressed interest in exploring how object- oriented modeling, specifically the UML, can be used for embedded systems develop- ment [37, 38, 39], UML lacks a formal semantics, thus precluding rigorous analysis of requirements expressed as UML models. An approach that integrates both semi— formal and formal techniques enables rigorous analysis early in the software life cycle. This research applies UML formalization to enable developers, who are not experts in formal methods, to use automated tools to validate (i.e., check their understanding of) embedded-systems requirements specified as UML models. While formalization of UML enables rigorous analysis of formal models derived from UML diagrams, formalization itself is not sufficient to broaden the community of embedded systems developers who can use formal methods to rigorously analyze requirements. To enable developers to model and analyze requirements in UML without having to know details of formal models requires a framework and process that takes advantage of a UML formalization yet insulates developers from the formal 3 ol~ s g. . v ‘ -n- ‘ n , . I v .- .. . .. .. . ... o .0. .4 .‘_ - . ‘- ‘ . Q, . 1' . s. '« O c -‘ » “ ‘. ‘- models produced by such a formalization. This research presents an approach to validating embedded systems requirements modeled as both UML diagrams and linear time temporal logic (LTL) properties using formal verification (e.g., model checking) techniques. We describe a model development and analysis framework that insulates the developer from formal models and outputs of tools, and an overall model development and analysis process that systematically applies the following steps. 1. Model creation. The overall process provides developers with model creation guidelines to both take advantage of a UML formalization and accelerate the initial development of requirements models. 2. Automated generation of formal models. Our approach complements and extends an existing general UML formalization framework for embedded systems development [31, 33] that supports the automated generation of formal models. 3. Automated translation of UML-based LTL specifications into target- language-based LTL specifications. Our approach enables embedded sys- tems developers to model requirements in UML and check the UML models for adherence to developer-specified LTL properties. The developer specifies LTL properties in terms of UML attributes, in-state predicates, and message recep— tion; these UML concepts are translated to their formalized representations and checked against the formal model derived from the UML model. 4. Model analysis. In order for developers to make effective use of formal analysis tools without being experts, the overall process provides guidelines for using the different analyses available, including using them in an integrated fashion. 5. Visual interpretation of analysis results. The overall process incorpo- rates visual-based feedback techniques relating sometimes cryptic analysis re- 4 v v y A. s . a h A I‘ ' o c .-a- ...._ . . .. , ‘ . ‘ 4 2c . .. .__. . - -. 9...... r. -. , s ‘ ‘9 . 9 < . V V - ~ , ‘ .‘ \ c W In..‘ t . ‘\‘ . \, ‘ ’V " A- 4: o . \,‘ rc- . \4 n V sults back to diagrams in order to insulate developers from the output of formal analysis tools. 1.2 Thesis Our approach to validating embedded systems requirements incorporates the follow- ing enabling techniques, described in the previous section: Model creation [40, 41, 42], o automated generation of formal models [31, 33], o automated translation of UML-based LTL specifications into Promela-based LTL specifications [40], 0 model analysis [40, 41, 42], and 0 visual interpretation of analysis results [40, 41, 42]. Thesis Statement: By using a combination of graphical model construction, auto- mated translation of models and critical properties to formal specifications, automated analysis of specifications, and visual interpretation of analysis results, a developer can make use of formal-verification tools to support model validation while being insulated from the formal models used by these tools. 1.3 Contributions This research had several objectives: 1. To leverage existing ob ject-oriented notations, formal languages, formal analysis techniques, and formal language analysis tools. 5 2. To keep as much of the underlying formal method(s) as possible transparent to the user while providing user guidance for instantiating requirements-based properties. 3. To explore the tradeoffs between different analysis techniques to determine which technique is most appropriate at different stages of modeling. 4. To leverage visualization techniques for displaying the results of well-formedness error detection (i.e., consistency checking) and formal analyses. An overarching objective of this research was to facilitate technology transfer of rigorous software engineering techniques to developers of embedded systems. To achieve these objectives, we developed a model development and analysis framework that leverages, integrates, and encapsulates a previously developed formalization framework for object-oriented notations [31, 33], thus enabling embedded systems developers to use formal-verification tools to support requirements validation while insulating the developers from the formal models used by such tools. We described an instantiation of these integrated frameworks with an existing object-oriented no- tation (UML), previously developed mapping rules from UML to an existing formal language (Promela), and an existing formal language analysis tool (Spin). We de— scribed and demonstrated a model development and analysis process that applies light-weight ( e. g., consistency checking) and heavy-duty (e. 9. model checking) anal- yses at different modeling stages, and leverages specification patterns by Dwyer et al. [43] to provide user guidance for instantiating requirements-based properties to be checked against a formal model. Results of structural and behavioral analyses are visualized in terms of UML diagrams in order to insulate users from the output of formal analysis tools. In summary, this research makes several contributions [1, 40, 41, 42, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56]: o Bifurca‘ . or .- V' K 4. . .. a ‘O . ' l ‘ . s .. . K .. a Visual 4... 51'} \ A Q ‘ ‘K- .. \. ‘ 'Q . l ‘ y . .5 s .‘ 9‘ . . \. p \ r\ V ‘~‘\ A‘ - a ‘ ‘ . o Bifurcated approach to analysis [40, 47, 51]. Preliminary investiga- tions [44, 45, 46] indicated that formal analysis tools are not well-suited to de- tecting structural problems within the formal models generated from diagrams; that is, diagram well-formedness should be checked prior to formal model gener- ation. Therefore, we describe and demonstrate a bifurcated approach to analysis that incorporates both structural (diagram level) and behavioral (formal model level) analyses. 0 Visualization of analysis results to guide diagram refinements [40, 41, 47, 50]. We developed visualization techniques for results of both structural analyses of diagrams and behavioral analyses of automatically generated formal models. Visualizations include highlighting portions of diagrams, animating diagrams, and generating new diagrams. 0 Framework and process for development and analysis of (formalized) UML models [40, 41, 49, 56]. We developed a model development and anal- ysis framework (Chapter 4) that leverages, integrates, and encapsulates a previ- ously developed formalization framework for ob ject-oriented notations [31, 33], including feedback to diagrams from formal analysis tools in order to insulate users from the outputs of such tools. We also developed an iterative and in- cremental model development and analysis process (Chapter 4) that comprises steps for (1) model construction, (2) structural analyses, (3) behavioral analy— ses, and (4) refinements based on feedback from both types of analyses. 0 Structural and behavioral patterns for modeling fault handling. High- assurance systems must often remain operational even in the presence of faults. We developed structural and behavioral patterns for modeling the fault- tolerance concepts of detectors and correctors [57] in UML to provide guidance for modeling and analyzing fault handling requirements. 7 —< . I' ' ’ -‘.- .u. a . l v ~ v I a.¢ n . ~ .. v . , -. .. ... 5‘ .. . u | w r, qv .- , - 6‘ I .4 4..A ‘ ¢.o ' r V}v . . -. .. ' . . -- o " ‘ h -1 I .- -- * v w. -- .-._-__.‘._ . . '-r.- ‘f I - ~ ‘ -m .‘t 3 . . -_ ‘ . ~-H“‘ I 7" O». ._‘ 7 N1. 4 -‘. .\‘ ‘ o T ".-_,. s . r . <~ ‘ ._“ J a. ‘ . v V ~ . .‘ .‘ ‘. > . I. .\ ‘A . . *v— ‘ "e..‘. . \t .. ' V 1 r. ..i - \L‘- o W x" K 5 -.~ A u.- a’ ‘ i‘ A . ‘e-.\ ‘ .‘ \ ‘x \‘ *. . ‘,_ \v. ~—' V. ‘ ‘ ‘1 i. .._ H ."\ ‘ L‘ \ . _‘ < ‘ sw" -¢ - \ ‘ “ ‘ 4 I ‘K~ .- .‘.‘ ‘n _ ~. ‘_ \ % HI 1.4 Organization of Dissertation The remainder of this dissertation is organized as follows. In Chapter 2, we present background material regarding two formalizations of semi-formal object-oriented graphical notations: Wang’s OMT formalization work [27] and McUmber’s general framework for formalizing UML for embedded systems [31, 33]. Wang’s formaliza- tion provides the context for our preliminary investigations, while we make direct use of McUmber’s formalization framework in our approach. Chapter 3 describes preliminary investigations with Wang’s formalization and general distributed sys- tems [44, 45, 46] exploring tradeoffs between different analysis techniques to see what analysis technique is most appropriate at different stages of modeling. The lessons learned in these investigations motivated our subsequent research with analyses and visualizations at different modeling stages as applied to McUmber’s UML formaliza- tion and embedded systems, described in the remainder of the dissertation. Addi- tionally, our model development and analysis framework, introduced in Chapter 4, leverages and extends the specification generator architecture used by both of these formalization approaches. We then instantiate this framework with tools to support McUmber’s UML-to-Promela formalization [31, 33], and we present a model develop- ment and analysis process based on this instantiation. This model development and analysis process serves as a road map to the remainder of the dissertation. Chapter 5 discusses both structural and behavioral analyses enabled by the formalization of UML, while Chapter 6 describes visualization techniques we have developed to relate the results of both structural and behavioral analyses back to the formalized UML diagrams from which models were generated. To validate our approach, we performed several case studies [40, 41, 42, 53, 54, 55] obtained from the automotive industry, including an Adaptive Cruise Control system [40] that uses radar to avoid collisions, an Anti—Lock Braking System [53] with redundant brake sensors, a self-cleaning Diesel Fil- ter System [41, 42] that removes soot from diesel truck exhaust, and an Electronically 8 Controlled Steering system [54, 55] that provides variable-assistance power steering; we present results from the Adaptive Cruise Control case study [40] in Chapter 7. In Chapter 8, we assess the cost of using instrumentation to enable visualizations in terms of the increase in the size of the state space (an important concern for model checking). We also discuss the applicability of the overall model development and analysis approach to other application domains. In Chapter 9 we describe how our model development and analysis framework can be applied to fault-tolerant systems, including the development of structural and behavioral UML patterns, as well as crit- ical properties. In Chapter 10 we review the related literature. Finally, Chapter 11 presents concluding remarks and outlines potential future investigations. Chapter 2 Background This chapter discusses two previous works that integrate semi-formal graphical model- ing notations and formal languages: the general UML formalization framework [31, 33] extended in this dissertation, and its predecessor, a formalization [27, 58, 59, 60] of 0b- ject Modeling Technique (OMT) [14] diagrams in terms of LOTOS1 [61] models. The latter was the focus of our preliminary investigations [44, 45, 46] of integrative anal- ysis techniques for formalized object-oriented diagrams. Additionally, in Chapter 3 we use examples from these investigations to illustrate both the need for consistency checking of diagrams prior to formal model generation, and the benefits derived from visualizing analysis results. 2.1 Formalization of OMT Wang et al. [27, 58, 59, 60] described a set of rules and a process to enable the semi-automated generation of LOTOS [61] models from OMT [14] diagrams. Our preliminary investigations [45, 46] examined the types of analyses afforded by this formalization using existing LOTOS analysis tools. We provide a brief overview of OMT, LOTOS, and two LOTOS analysis tools, followed by a high-level overview of 1Language of Temporal Ordering Specification 10 I) 'N ' _ ‘_ - .t‘ u . . . \. K‘a‘ 1 ~‘.:‘ II. ‘ c A. t ‘ . A" 7' 1 N'. _ 4 . “‘0 . 2 ,. . A \ C s.~ [ . ‘ ' . S‘- «V H. : v o “‘5 . . ~~. ‘ I. - . ‘ H"\. . _ . A s V .. .. h. . ~. L. ' ~. . v ‘ P. «3‘ .2- . , “ .‘_. v . ‘~. p .37 \ ”a \ _ .‘fila ‘- T' ’ l - - V '5- -“ ; . -‘~“. . _. . ‘ ‘6 ..~ . ~‘. ‘~. " O \ \—‘~ ' , - a \Q ‘;‘. ‘. Wang’s OMT-to-LOTOS formalization rules [27]. 2.1.1 OMT Overview The Object Modeling Technique (OMT) [14] uses three simple graphical notations in a complementary manner to express structural, behavioral, and functional character- istics of a software system. The object model depicts static structural information; that is, the objects comprising a system and the relationships between those objects. Furthermore, this model provides the context for the other two models, the dynamic and functional. While the dynamic model portrays the behavior of the system and its objects, the functional model captures the data and the services of the system and its objects. The three orthogonal models are briefly discussed in the following text. Object Model. An object model depicts structural information about a system. The object model of a system consists of a class diagram; that is, a diagram consisting of boxes and lines. Boxes represent the classes or objects comprising the system, and lines denote the relationships or associations between them. Each class has a name and may be adorned with text denoting a list of attributes and their data types, or a list of operation signatures. Associations may have a filled or hollow circle at their endpoints to indicate multiplicities of many (zero or more) or optional (zero or one), respectively. Multiplicity of exactly one has no special adornment at the endpoint, while one or more may be indicated with the text “1+”. A triangle or diamond at one endpoint denotes sub-typing or aggregation, respectively. The Unified Modeling Language (UML) [16, 17, 18], discussed in Section 2.2.2, has incorporated most of the OMT-style class diagram notation for its class diagram. Dynamic Model. The dynamic model of a system describes the behavior of the system and its objects via a collection of state transition diagrams. Each state dia- gram depicts the permissible sequence of states and events for one class. The notation 11 Class_l attrl : int attr2 : real Class_3 opn l () : bool <> opn2(char) : void h Class_Z Class_4 Figure 2.1: Example OMT class diagram is based on Harel’s Statecharts [62] with slight variations. Rounded rectangles anno- tated with names represent states, and labeled directed arcs represent state transi- tions. States may be simple (flat), composite (containing nested states), or concurrent (having partitions each containing a state transition diagram). The label on a transi- tion may contain the name of the event that triggers the transition, a guard condition, or an action such as sending an event to another object. The UML has also adopted most of the OMT-style state diagram notation for its state diagram. Fllnctional Model. A collection of data flow diagrams portraying the data and services of the system and its objects comprises the functional model of a system. In data flow diagrams (see Figure 2.3), ovals annotated with names correspond to processes, and directed arcs correspond to data flows. Arcs are labeled with the data type and optionally the data name. The UML does not include data flow diagrams. 12 ( Composite] \ ;’ Partition] 5 ] State__B ] l 5 132[]/ l E l E E State_C l :' Partitionz ‘; 5 ( CState_D \ f Figure 2.2: Example OMT state transition diagram d4 : Type4 d2 2 TypeZ Figure 2.3: Example OMT data flow diagram 13 1., ‘0 2.1.2 LOTOS Overview LOTOS [61] originates from the telecommunications industry as a specification lan- guage for networking and telecommunications protocols. Basic LOTOS is built upon a process algebra, enabling specifiers to model externally observable behaviors, or events. A process algebra is an algebraic theory that formalizes the notion of con- current computation [63]. Full LOTOS includes an algebraic specification language, ACT ONE [64], to enable specification of abstract data types (ADTs) and modeling of process communication via data exchange. Algebraic specification can be used to define relationships between ADTs in terms of operations on them [65]. A full LOTOS model may include definitions of abstract data types in addition to process descriptions. Each process in LOTOS has an identifier, a formal gate list, and a description of its functionality including behavior expressions. Each behavior expression is built from primitive actions or events and predefined operations such as action prefix (;) for sequentiality, choice ([1) for selection between alternative behaviors, and parallel composition (I l) for concurrency. A full LOTOS event consists of its name (known as the gate) and a parameter list. Processes may exchange data if they synchronize on a gate; that is, one process offers (l) a value at the gate and another process accepts (?) that value into a variable of compatible data type. For example, in the LOTOS code fragments shown in Figure 2.4, process A offers the values contained in its variables x and y at gate foo, while process B waits at gate foo for an offer of two values, one of type Int and one of type String, respectively. If x is of type Int and y is of type String, then processes A and B may synchronize on gate foo, with process B’s variables w and 2 taking on the values of process A’s variables x and y, respectively. This type of synchronization is known as value passing. The behavior of a LOTOS model can be represented graphically by a Labeled Transition System (LT S). An LTS is a tree-like structure with anonymous nodes and labeled arcs. Labels on arcs represent events, or occurrences of actions. The root of 14 endproc processA(sender) : foo! x! y; processB(receiver) : foo ? w: Int ? 2: String; Figure 2.4: LOTOS synchronization with data exchange process Soda [75c, PepsiButton, DispensePepsi, CokeButton, DispenseCoke] := noexit 75c; ( (PepsiButton; (DispensePepsi; Soda [75c, PepsiButton, DispensePepsi, CokeButton, DispenseCoke] )) (CokeButton; (DispenseCoke; Soda [75c, PepsiButton, DispensePepsi, CokeButton, DispenseCoke] )) ) endproc Figure 2.5: LOTOS model of recursive soda vending machine the tree appears at the top of the structure. As an example, consider a soda2 vending machine modeled as a single LOTOS process (Figure 2.5). In this model, the vending machine first accepts 75 cents from the customer. Next, the customer may choose either Pepsi or Coke by pressing the appropriate button, causing the vending machine to dispense the desired beverage. The vending machine then awaits the next customer. Note that this model is an extremely simplistic abstraction and so does not take into account details such as making change or indicating when a particular brand of soda is not available. As shown in Figure 2.5, the choice construct selects between two alternative be— 2Pepsi and Coke are registered trademarks of their respective companies. 15 ' . v ] . A. ‘ . . c . , v a l .~'VI 9 | V. \ v. v- ‘.. a ‘1 \ , .. A (lP . . ‘ . w .... " r .. . ‘- ‘ V . o ‘ ‘ . . w" L..‘ - A . IIP ‘ C ‘-—-‘ ‘——_‘ ‘~ 75c ,' \ PepsiButton CokeButton , x \ DispensePepsi DispenseCoke , I ‘——‘ ‘~—— Figure 2.6: LTS of recursive soda vending machine haviors (purchasing Pepsi or purchasing Coke) based on the next event (pressing the appropriate button). Modeling a choice between two behavior expressions 81 and 82, the expression 81 [[82 behaves like 81(82) if the next event is the first event of behavior 31(8)). The noexit operator is used for defining recursive process in- stantiations. This construct, together with process instantiation, allows modeling of repetitive or even infinite behaviors. In Figure 2.5, after dispensing a beverage the vending machine awaits the next customer. A choice can be shown in an LT S as a split or branch from the node representing the choice operation, with the behavior tree for B1(Bg) appended to the left (right) branch. Repetitive behavior can be shown as a dashed arc looping back to the start of the behavior. Figure 2.6 illustrates both alternatives offered by the vending machine (purchasing Pepsi or purchasing Coke) and its return to awaiting the next customer. 16 2.1.3 An: IOPO LOL 1 o I v . U ' . ¥I\ I. . .o a. . o 'n «u. ‘ . ‘I . - n . o , _‘ '- v- ‘,p H . ‘ 1‘ _ .. - " v \ ‘. a .' ‘ “A ”~ ".. A ‘ . U- I ., " nun. .. . T-.. FF 0 V ‘ ’ I .A‘“ .‘.H.~ ‘ .. . a»- '. ‘ " \ . .a__ . . . ‘ ‘ - . I» , ‘1‘. . o . > ‘5 ..‘ . A.-. “‘ .‘ .‘l . . ‘. v. , ‘ r. h ‘ ‘ Q-.. - “ v‘. l. ‘ v . 'V I \|— v ’ ‘~«~ ‘ A” ~ ‘r .‘ .‘ I ' ‘ ‘ N... G‘."‘l“ .Q P. . v 1“ . ’ . "i ‘ “ -.. I . h ’ ‘ ‘7 . -..,‘. . . ,.A .“ ‘ .’ ._ ‘ I. ‘ - ‘m bo“ “ w l . i 'a A . 'r a S“ L." ,,_ . C T V n”; ‘ '~ < A“.\ ‘ . K‘ “ 2.1.3 Analysis Tools for LOTOS TOPO/LOLA Overview. TOPO3/LOLA4 [66], a LOTOS tool suite developed by the University of Madrid, offers syntax and semantics checking of basic and full LOTOS models. TOPO can handle “incomplete” models; that is, not every operation needs to be fully defined with algebraic equations. LOLA, a transformational and state exploration tool built atop TOPO, provides several types of expansion (state space generation), interactive simulation, and test composition. CADP Overview. CADP5 [67], developed by INRIA and Verimag, also offers syntax and semantics checking of LOTOS models, as well as interactive simulation and test composition. However, its additional features for viewing, manipulating, and comparing LTSs do not have a counterpart in TOPO/ LOLA. Phrthermore, CADP supports automated comparison of the LTSs that represent a design before and after refinement, the generation of counterexamples for deadlock cases, and the verification of temporal logic properties against LTSs. 2.1.4 Formalization Overview Wang et al. [27, 58, 59, 60] formalized the OMT models in terms of full LOTOS syntax that allows the information expressed in the graphical object, dynamic, and functional models to be captured in terms of algebraic specifications and process algebras. The commonalities between the ACT ONE algebraic specifications and the basic LOTOS process algebras induced by the formalization rules make it possible to integrate the object, dynamic, and functional models into a full LOTOS model. Figure 2.7 contains a high-level overview of the OMT models and their corresponding LOTOS formal models. Overall, instances of classes or objects are represented in LOTOS 3Toolset to support product realization from LOTOS specifications 4LOtos LAboratory 5Caesar/Aldebaran Development Package 17 .r“ ." 3 ‘ _. r. v nl r' ‘ - . ‘1-9‘ ' .-\ ' '4 ‘M Object .‘l Dmamic .\li Fchtional .\l 1' up“ n u ‘2? - . if N h : i . 'K r . a A" H ' ‘ ‘ Q 1 I by a combination of abstract data types and a process instantiation. Each state becomes a subprocess, and each state transition an instantiation of the destination state subprocess. Object services, or the events to which objects respond, are realized as synchronization and data exchange between processes. Object Model [:> Dynamic Model :> Functional Model ::> samu uonezueuuod {)0 :> Algebraic Specifications Objects as ADTs Process Algebras States as processes State transitions as process instantiations Algebraic and Predicate Specifications Data flows as sorts Services as operations Pre- and postconditions Figure 2.7: Overview of OMT-to-LOTOS formalization rules 2.2 Formalization of UML McUmber et al. [30, 31, 33] built on Wang et al.’s approach by describing a general framework to attach formal semantics to any semi-formal diagrammatic notation(s). They then formalized a subset of the Unified Modeling Language (UML) [16, 17, 18] relevant to embedded systems development in terms of both VHDL6 [68] and 6VHSIC Hardware Description Language 18 ". .4‘ r. -‘ . P ..; . . . ‘ v , - v ' a . Li a. II >_‘ . . 5L9 ‘ ,_ pox o v \ .N . x . -. ‘- '. . o v . . u .n . - . n - . , . .. A... . . .i a . -\ \ o . 2.. ~ I 4 “-55-- . l n-... ... , ~ .0 n- | H" .. \ .' k“ A. . . D. ' a “- ‘ ’“e .I.‘ -. V . .- __v ,. a \ .' -u J] . .,L . .. 1»- H . -.., - . a. V . § “L 4 ‘. ‘ t . h . w: ‘v." 4. , a _' ' . .."\\ ' A“ . 7b ‘. .“ . . . ‘ \ 0 -. ‘~._"‘ I A - . .g b ‘ b . V ‘ i ‘u, ‘~‘\ 7. u . 'I s. we, ' r- A ~ . a. - . . . -. ' l '. P. X- . .‘ , _ Q . . Promela7 [69]. Our research extends this general formalization framework by pro- viding a graphical editing and visualization environment [50, 51] both for drawing the UML diagrams comprising a system and for visualizing analysis results. Our efforts to date have focused on McUmber’s UML-to—Promela formalization [31, 33]. Therefore, we include a description of not only UML diagrams affected by the for- malization (e. g., class and state) but also UML diagrams used in displaying analysis results (e.g., sequence and collaboration), and we briefly overview Promela, the input language for the model checker Spin [69]. We then provide a high-level overview of Spin analysis tool suite and McUmber’s UML-to-Promela formalization rules [31, 33]. 2.2.1 General Formalization Framework Wang’s approach [27], as shown in Figure 2.8, creates mapping rules from a semi- formal language model (OMT notation) to a formal language model (LOTOS). How- ever, his approach does not provide any guidance regarding where, how, and why to create mapping rules. McUmber’s approach [31, 33], on the other hand, provides a general framework to guide the creation of mapping rules. As shown in Figure 2.9, his approach is based on mappings between metamodels, where a metamodel is a class diagram that describes the constructs of a modeling language and the rela- tionships between the constructs. Relationships between metamodel elements in the source (i.e., UML) constrain the mapping rules to realize the semantics of each major construct in the semi—formal language metamodel in terms of the formal language. 2.2.2 UML Overview The Unified Modeling Language (UML) [16, 17, 18] comprises a collection of diagram- matic notations that depict an ob ject-oriented software system. A product of the Ob— ject Management Group (OMG) under guidance from Booch, Rumbaugh, and Jacob- 7Process or Protocol Meta Language 19 —————- Semiolurm Sum-l. -rm.1 \ Sfflu‘iur \ *1, \T v, '- - l "a o o.- 'v (\ x | - .‘~.‘\. ‘4 . ,- V» 1 F . ‘ I. a. l . ‘k. ‘. - ‘ ‘uo‘ 4“ . ‘a, ‘ 7. -‘N N » ‘ . ‘ I . .- i“ ~ - a. ‘I, v ‘ . . x x ._ 4 . ._‘. w . ‘ \o u '.s ~A‘ '§ .‘ \ ‘. A 9 Semi-formal language model p Formal language model mapping rules Figure 2.8: Unconstrained mapping from semi-formal to formal model relationships Semi-formal language metamodel > Formal language metamodel constrains constrains constrains instance rules instance Semi-formal language model > Formal language model mapping rules Figure 2.9: Constrained mapping from semi-formal to formal model son, the UML incorporates and extends several modeling languages, most notably the Use Case Diagram [15], Object Modeling Technique (OMT) [14] and Statecharts [62]. The UML contains several distinct types of diagrams to depict the structure (Class Diagrams, Object Diagrams, Component Diagrams, Deployment Diagrams) and be— havior (Use Case Diagrams, Activity Diagrams, State Diagrams, Sequence Diagrams, Collaboration Diagrams) of a system. This research focuses primarily on the class, state, sequence, and collaboration diagrams. As noted in Section 2.1.1, UML class and state diagrams use notation similar to that of OMT’s object and dynamic models. Class Diagram. As in the class diagram of the OMT object model, the UML class diagram depicts the classes in the system and the relationships between the 20 .\v‘\ .:. ”an - -. .. . I . u. a t - u n A. . ., t .. o. . . p- . a l A. ‘ u o u o v A‘ r. . 4 .ce‘ ..4 r. 1‘. a- - 1. .. " " \ .4 A: . _ _ ’-v . . 4 _ . . , . l' . .‘K‘ ‘ . .L A > _ ' h r ‘ , .I V -‘ AI .- .... 4 ‘ f ' \ . . ‘ . . a ‘ _ y' . ‘ ..‘. ; L \ A . ~,. - A s . V‘ ’ . . ."".. S -“| ~ . . O s‘“ . ‘ >0 y.“ ‘1 .q- ‘u ‘ ‘ t I § \ . ' .— ‘r ~._ a' a »~ .~‘\ . I nLY7 . - s s ‘ ,\,,fi ,. 4 A. 4’ fi-_ H H.’\“ v. . o. ‘ ‘ I . a .‘1 —q A, , I " -- . \_ .7 ._ T‘ '1 ‘u - “- \ . ‘I 0 ‘; -~ \.‘ . "_ “ t \ \ ‘x‘w 9‘. , _ -. . .. t“ ~s .-_ . x‘ p. - s \ Q 0 ‘. _. C . a T\\ f‘ r classes. Classes are drawn as boxes. Each class is labeled with its name and may additionally contain a list of attributes and their data types, and a list of operation signatures (including optional parameters and return types). Relationships between classes are drawn as lines, possibly with adorned endpoints, between them. There are four types of relationships between classes. The most general, association, is a binary relationship between two classes. Three additional relationships are subtype, aggregation, and composition, which are drawn as a small hollow triangle at the superclass end, a hollow diamond at the aggregate end, and a filled diamond at the aggregate end, respectively. Multiplicity on an endpoint is indicated numerically, with the number applying to instances at that end of the line. An optional instance is denoted by “0.1”, “*” indicates 0 or more, and “1..*” denotes one or many. State Diagram. Similar to the state diagram of OMT’s dynamic model, the UML state diagram notation uses many Statechart [62] conventions to describe the dynamic behavior of objects. States are drawn as rounded rectangles with transitions between states depicted as directed arcs between the rectangles, indicating the direction of the transition. Transitions are labeled with an event followed optionally by a guard (enclosed in brackets), a forward slash, an action list (separated by semicolons), and a message list (separated by carets). Composite states may contain further sets of state diagrams. Concurrency of composite state machines is indicated by separating the composite states into partitions with dotted lines. Sequence Diagram. A UML sequence diagram depicts objects and the ordering of messages that are exchanged between them within the context of a behavior scenario. As shown in Figure 2.10, objects are depicted as named boxes along the .7: axis, each with a line, the object’s life-line, extending beneath it parallel to the y axis. The life-line may be a single dashed line, or in the case of concurrent objects, a rectangle. Messages exchanged between objects are drawn as labeled arrows between the life- 21 Callahan] lU a .‘. ["w . ' . i I. ‘ ‘ t.‘ ' p _ " ‘U'. . ' w[ .. A .5, .. (‘ ‘ ._ ‘ 'h.~ ° .~ -. “I \ \ V- ] > . . ‘ . v ' ‘ A | ‘. 7‘~~ ‘ . ’; , .'_ : ‘s. ‘] ‘ ‘ d A-\ a ‘ o b v (1\ . .‘- .. N- . O, . ‘ a.-<.>73 5.. . .‘ ' t V . Pb- . ~\;\ ‘3... vv ‘~‘ I a ‘. . 7 4, ’9. ‘ A‘ 1“ 4 ".5 ,__ ‘ ‘ ‘ ‘e. r‘ S. .‘C \ ‘\ V .\ -, \ T “ r4 lines of the sender and receiver objects. The messages are ordered in increasing time along the y axis. c5 : Class_S C6 3 (3885.6 c7 : Class_7 message_l (param__l) message_2 message_3 Figure 2.10: Example UML sequence diagram Collaboration Diagram. Isomorphic to a sequence diagram, a UML collaboration diagram also portrays objects and the messages that pass between them within the context of a behavior scenario. A collaboration diagram, however, emphasizes the objects’ structural organization rather than the temporal ordering of the messages they exchange. As shown in Figure 2.11, objects are depicted as named boxes, while the paths of communication, or links, between objects that exchange messages are drawn as lines between the boxes. These lines are adorned with labeled arrows that indicate both the messages themselves and the direction of the messages. Messages may be prefixed with a sequence number to indicate temporal ordering. The box depicting an object may also include information about values that may change over time, such as the object’s state or attributes of interest. Other Diagrams. The UML also contains other diagrams depicting a software system’s structure (Object Diagrams, Component Diagrams, and Deployment Dia- grams) and behavior (Use Case Diagrams, and Activity Diagrams). However, work 22 c5 : Class_S attr_l = 3 2 : message_2 ] c6 : Class_6 ] 3 : message_3 attr_l = 0 l : message_l (param__l) ¢ c7 : Class_7 attr_1 = 9 Figure 2.11: Example UML collaboration diagram to date has focused on the Class, State, Sequence, and Collaboration Diagrams as relevant for modeling embedded systems and visualizing analysis results. 2.2.3 Promela and LTL Overview Promela8 [69] is a C-based language originally developed by Bell Labs to specify telecommunications protocols, but it has gained increasing use in other industrial domains involving distributed systems. Promela models consist of processes, chan- nels, and variables. Processes are global objects, created dynamically, that execute asynchronously. Channels and variables may be either local or global. Processes communicate via unbuffered or buffered channels. 8PROcess MEta LAnguage 23 . a « UC" ‘ . n- , ., ‘b A. s. - ‘ ‘ ‘ - o . . H. 7 . . ‘ H ..... I ”4- . w o . - o. y 1 l . ‘t‘., | 4.. . .- o r. ‘y ’ x. '- w \ a .,. - . ,. , ' .o . I ‘ ' ‘ ' " o. . n . . . ‘ ‘ \ . . -. I _.. u ' \"' b I . N ‘ A .- A e, r . f r- _ lr- ' ~ ’ . In . ‘ . I V, o - . N 4 V‘.‘ O 6‘ “\'-l.. t. .. v- _ l I. 7 V V s. _ ~t , v A. _ . ‘ I y- ‘T "r , ‘0‘ a- ‘ “' ‘~_|‘ I ‘1 .' . 5‘ v. .. , u ‘.o t. i . ,. . 1“. ‘ ‘ W! . e_ { x “ ‘ “- ‘. _~ ’4‘ 4.- ] O . 0 . Q .— .' ~..'f v .‘.‘ a .‘ 7‘ v‘ ‘. M_‘._ ‘ \ I I. . a | 'n '1" , ~..~' . ‘ < a,‘\ £‘~. wen. -. N 2.2.4 Analysis Tools for Promela A model written in Promela can execute in a simulation environment, or model check- ing techniques can be applied to verify a number of temporal properties, including safety and liveness. Spin [69] (used in model-checking mode) verifies claims written in linear time temporal logic (LTL) [5] against a model. LTL extends propositional logic with temporal operators that apply to a sequence of states, such as the unary operators henceforth (El) and eventually (O). D means that the operand is true at every state in the sequence, while 0 means that the operand is true at some state in the sequence. Some variants of LTL include a unary next (0) operator, meaning that the operand is true in the next state in the sequence; however, the default in Spin is to disallow this operator as it exacerbates the state explosion problem.9 Thus, we do not consider properties containing the next operator. LTL in terms of UML. As a convenience, McUmber developed a utility that enables users to specify LT L claims in terms of class, state, attribute, and signal names from UML diagrams, and then translates them into the Promela variables and syntax required by Spin. Acceptable terms include c1assName.attributeName to reference the value of a particular attribute of a given class, in(className.stateName) to test the condition that a given class has currently reached a particular (UML) state during its execution,10 and sent (className .messageName) to test the condition that a given class has been sent a particular message. LTL operators henceforth (Cl) and eventually (O) are given to the utility as [l and <>, respectively. 9Because of what is known as the state explosion problem, model checkers in practice must use some technique, or combination of techniques, to reduce the state space explored. Spin in particular uses the partial order reduction to limit the number of interleaving sequences considered [69, 70]. 10A state predicate term in an LTL claim causes Hydra to generate an extra boolean variable that becomes true when Promela execution enters the part of code corresponding to the UML state, and false when execution leaves that part of code. 24 Specificat in? O W [17:52": 5' ' .... . .. a. 9' I4 "a “W... n t‘- A V V ‘ I! I‘ ‘ .. . A I O. H? . ‘ O .W a .. n 1, . .. am ,. _ . . .. u- , -. ..v‘. ‘1. \ in, y: A . A l :.."‘v - ‘ *‘ .a.. 2’) ' .~l' y. § 8 '_ . t’. 7'. sj‘ v. N v .‘n 5‘ A \ A' x “’-A ‘ V» “"l I- ~"‘ ' \‘_ ,Ir \ . \ . TI .. an ‘ “H', , .. .N , ~a Specification Patterns. We have found the specification pattern taxonomy by Dwyer et al. [43] to be useful when attempting to write formal temporal logic prop— erties (i.e., LTL claims) based on English natural language requirements. The speci- fication pattern repository organizes common specification patterns into a taxonomy based on order (e.g., response, precedence) and occurrence (e.g., universality, absence, existence). Specification patterns are expressed in a number of temporal formalisms, including LTL, and include suggestions for typical use. While most of the properties that we have explored to date fall into the globally—applicable format of their two most popular general categories, response or leads-to (e. g., D(p ——> Oq), meaning that it is always the case that when p is true, q eventually becomes true) and universality or always (e. g. Clp, meaning that it is always the case that p is true), Dwyer et al.’s addition of non-global scopes to the property patterns makes it easier for a developer to define complex properties that apply to only a portion of system execution. 2.2.5 Formalization Overview Figure 2.12 contains a high-level overview of the UML class and state diagrams and their corresponding Promela specifications. McUmber et al. [31] formalized the dia- grams according to the following diagram integration conventions: (1) Each class that has a modeled behavior has a corresponding state diagram that expresses that be- havior. We say that this state diagram belongs to or is owned by the class. (2) Events to which a class reacts may appear as events on transitions in the state diagram be- longing to the class, but must appear in the operations list of the class. (3) Variables used in a state diagram must appear in the attributes list of the class that owns the state diagram. The UML-to-Promela formalization rules are based on a constrained mapping between the integrated UML class and state diagram source metamodels and the tar- get language Promela metamodel. Classes are mapped to Promela type definitions 25 . c O ‘ f 'w r x ‘\ 7‘ ‘ I u 9 . . ,. . ] .\‘\\ O ,3 0A» \ ‘. 0 y ' vy- ' k 6 <0 ‘ I G .c y o o o 1 ' ‘ A4 .a . A n - . \~ . 0- 01 n u...- .~ . v u l , v s . 0 ‘~ I .1 .' ‘ ‘ q o ‘ -~4-- ....-'_ .._ Class Diagr; Slate D13,“ (typedefs), with class attributes mapping to variable declarations within a typedef. A class’s behavior as represented by state diagram is mapped to a process description (proctype) with simple states as labels and transitions as gotos. Composite or con- current states are mapped to separate subprocesses. Events on transitions become message receptions while actions become either assignment statements or message sends. The formalization rules provide a queueing mechanism between objects for handling inter-object communication. Class Diagram :> State Diagram [:> > Type Definitions - Classes as typedefs - Attributes as variable declarations Process Description - State diagram as proctype - States as labels or subprocesses - Transitions as guarded gotos - Events as message reception - Actions as assignments or sending messages samu UOflBZHBUJJOJ Figure 2.12: Overview of UML-to-Promela formalization rules 26 Chapter 3 Preliminary Investigations: Highlights and Lessons Learned Using Wang’s approach [27], we performed preliminary investigations of integrative analyses and visualization-based feedback for OMT diagram refinement in two case studies [45, 46]. In the first study [45], we examined how two different LOTOS tool suites (TOPO / LOLA [66] and CADP [67]) can be used in tandem to analyze formal- ized OMT diagrams, using the Environmental Information System (ENFORMS) [71], a multimedia distributed decision support system, as a running example. The second study [46] explored in more detail the types of analyses available with the CADP tool suite, including how they can be used together, and illustrated the visualiza- tion capabilities of the tool suite. We used a variation of the Teleservices and Remote Medical Care System (TRMCS), the suggested project [72] for the Tenth International Workshop on Software Specification and Design (IWSSD-10), as a running example. This chapter presents highlights from the case studies and discusses additional lessons learned that have motivated our later work with McUmber’s UML-to-Promela for- malization [31] and the Spin [69] analysis tools. 27 VD: Q l 0 ‘ l h ., . , .- l . - - . . . . ‘ . J. “u..- . . . . . o i ‘ ~ W~ \l‘ . -2. A . . ~hv ”0 . . ’ II . ' "' I I a . I K. ' ‘ O P\\ ' . :- . ... _ . . Al l . ll ' ;v .. ‘ h —-1. .. . ‘ x I. * V A >-" 'y ‘ko . , h " I... . ' . u ‘v ' 9 v. T‘ “‘ -.' . ... . 7"- ~ - xg. . \ >'I—~ “‘ ‘v ,. a. , ‘.‘ .- a .M'" ‘ ~-x. (‘1‘ .L‘l H . ‘.‘ ‘ l. ‘ ‘A. .. “\ H \ ‘~o - I _\. _ “ . . -~\‘ . 3‘- w . N . C-~ ' - ..‘ . ‘\ .,_ ‘ c ". ‘ . \ w. . __-., _. v " ‘-w \' ‘ «Q ‘ -‘ .,. . 9- \“~‘" \ ~‘ \ ‘ " ‘ g - a - ~. 4 . i- ,- 5 7 . . «A, “ "c \ ..~- \ Ir. a ’ \ X 3. 1 Highlights In [45, 46], we developed an analysis process to be used in tandem with Wang’s iterative design process [60] (see Appendix A, page 234, for a high-level overview of Wang’s process). We also investigated using two different LOTOS analysis tool suites (TOPO / LOLA [66] and CADP [67]) in an integrated fashion, and explored the output options of each of the analysis tool suites. This section overviews our analysis process, integrative analyses, and example output from the tool suites. 3. 1. 1 Analysis Process Our analysis process (Figure 3.1) supports analyses of OMT diagrams created or re- fined in each iteration of Wang’s design process [60] via the LOTOS model derived from them according to Wang’s mapping rules [27]. Structural and behavioral analyses are shown as boxes above and below the horizontal dashed line, respectively, in the process flow diagram in Figure 3.1. First, structural analyses (syntax and semantics checks) analyze intra— and inter-diagram consistency. Further, they check algebraic equations (manually) added to the formal model by the developer, if any, for LOTOS syntax or semantics errors. Structural analyses must be performed each time the LO- TOS model changes; that is, each time the OMT diagrams from which it is derived are modified (causing re-generation of the LOTOS model), or each time the developer adds or refines an algebraic equation. All structural errors in a set of diagrams or its derived LOTOS model must be corrected before behavioral analyses (simulation and state-based exploration) are enabled. Simulation can be used to validate require- ments, to increase confidence that a system or object in question behaves as desired, or to debug erroneous behavior. Once simulation has established a reasonable level of confidence in the model, state-based exploration can be used to find more subtle flaws. Techniques include concurrency analyses (e. g.. deadlock detection), test com- 28 r ”‘ Y ‘ l\... ‘., ma.- . - .71: " .0. O .0. P a --r-- -v ‘ . l.<-\ A ‘.. ah.- , .. 7 v ‘rfl . . I _.‘A --. . V v~ - .. . .4 _ . L . \o g-‘ .. .. . . . w. v a . \ a~ A.-.bn .- ... . . ‘ . o >4 . ..- ....-- ._ . . . v» s . _ V‘ ' u..- . . ‘ A.. h, . . , H .7 . n. A. “ - . ya u. u. . u , g ., °~~- .-,' . ,- . h V ’ O r -\A., ‘ . . _ ‘ R. in ‘\~' ., . up” ' -« J a . " '- F V..." -l "‘- A _' p. . ~ A. .’ 0‘ ‘ s. '~~., . . . . . . \ - 4 i A. ‘ V'. 6“ 5 r‘ a c. N_ '. ‘ W. 1 v ‘ . _ n . ‘ . a ‘~~¢_‘ ‘ k ‘F < 5.. a‘ v, . Q a.. ‘ .. ‘ . ., t > s . . ~ \. § 1..» .. , 4" ..‘ . o. ‘ I J, . g . . -x . . ‘ position, and refinement checking as shown in Figure 3.1. Deadlock usually indicates an error in inter-object communication. Composing a test process, a LOTOS process describing a desired sequence of actions, with a LOTOS model detects whether that sequence of actions is possible in the model. (Searching the LTS1 graph corresponding to a given LOTOS model for a pattern describing a desired sequence of actions is a similar technique not available in all LOTOS analysis tool suites.) Finally, refinement checking the LOTOS model derived from a set of OMT diagrams against the LOTOS model derived from a refinement of the same set of OMT diagrams can test whether the behavior of the refined model is equivalent2 to the behavior of the original model. (Refinement checking is not enabled until the model has undergone at least one it- eration of refinement in Wang’s design process [60], indicated by the dashed arc in Figure 3.1.) As illustrated by the solid feedback arcs to the topmost process box in Figure 3.1, flaws found with any behavioral analysis technique or combination of techniques must be corrected in the diagram(s) before beginning the next iteration of Wang’s design process [60]. The diagram corrections are checked by re—generating the LOTOS model, applying and passing structural analyses, and applying and passing the appropriate behavioral analyses. 3.1.2 Integrative Analyses The analysis process mandates performing structural analyses before behavioral anal- yses, and suggests performing behavioral analyses in order of increasing effort needed, either in terms of time/ space required to perform the analysis or on the part of the developer. Of the behavioral analyses available with either TOPO / LOLA or CADP (some analyses are available in one tool suite but not the other; see Chapter 2, Sec- tion 2.1.3, page 17 for a brief comparison of the tool suites), we found simulation, 1Labeled Transition System. See Chapter 2, Section 2.1.2, page 14 for a description. 2Depending on the LOTOS tool suite used, there may be several options available for the equiv- alence relation between the behaviors of the original and refined models, including strong bisimula- tion [61, 73], observational equivalence [73], and safety equivalence [74]. 29 Correct error(s) in diagram(s) Correct error(s) in LOTOS model(s) l Syntax/Semantics ’ Checking Structural Analyses ____________________________________ }{-------_--_____- Behavioral Analyses < Simulation ll ll Concurrency Analyses ll f Test Composition Correct design flaw(s) in diagram(s) i Refinement Checking Figure 3.1: Analysis process for LOTOS models derived from OMT diagrams 30 ...0‘ Y.-\" ‘ .4 w -.A“ ~ ' i . . r. . v . II V... .a...-\ u . - .— 1 .. v .4 p- w lo _I t L . . f 'r‘\ -'o ' -4 . ,§‘ In . . F . V ‘ b. b . A A.. 1.. \.. ‘." L -' 91 i ‘ --« .aa \aa ‘ q a o \e-i .L l '9‘ ‘ to i" ‘ . 1 ~- --...'_ r3» . . y . . .‘ .,. FI‘:~ p."Y ‘ I ‘ -ao. O. .‘ y r v» . . .1 I ‘ u... . O . ' l 1 f I » ‘ -. .. ..“ \ ,. t._ ‘I . .\ ~, “'...f " ‘ .‘l E ' ‘ v w. l' . ‘ ‘ A. ‘t '- l v, ‘ fl. .. _ \\ "‘l" . ~ _,“lv ‘ . -.' 1- r I A ‘l'u l A, ; 2'...“ .l' I ' . ,' .33 ' a. ‘A‘ H ' V q. ‘ ‘ . a.‘ . - i. Ff ~ A ‘- t.. ‘\'v- . ‘x u“.- ‘ ., L -_ .)-4" v f .a .“~. . \ ‘ O - v t id‘. ' . ‘<\ ‘;? . - ‘ e , V . ‘n. ,:§'- v. . ‘ -xwv :Y ~‘ in r" . ,. ‘v t . . ’ l. VI . 1‘ _. . ~- 5| L . ‘ /l\ c ‘l. ' x‘~ ’ TN .\ AK- w‘ s- -— . 4‘ J. 9 l . .4 ‘e \\ , ‘ ‘. 2.1‘.,‘w . V concurrency analyses (e. g., deadlock detection, finding the shortest path to a deadlock state), test composition or searching for patterns in the LTS graph, and refinement checking to be the most useful. Simulation can be performed very early in the mod- eling process, exploring a single path through the LTS graph at a time and guiding the developer towards correcting more obvious flaws. State—based exploration tech- niques are more expensive than simulation in terms of time / space or developer effort required, so they are delayed until simulation establishes a reasonable level of confi- dence in the design. Global concurrency analyses ( e. g., deadlock detection) can be used to check for errors in inter-object communication, but otherwise do not require anything else from the developer. On the other hand, test composition or searching for patterns in the LTS graph requires the developer to provide either a test process to be composed in parallel with the model, or a pattern describing a desired sequence of actions for which to search the LTS graph. Finally, refinement checking requires a baseline model and a refinement of that model for comparison against each other. In addition to being used on their own, each analysis technique can take advantage of the less expensive techniques; for example, once a deadlock has been detected, simu- lation can be used to demonstrate the sequence(s) of actions leading to that deadlock, facilitating understanding of the cause of the problem. For illustrative purposes, we focus our discussion of integrative analyses on a few examples from the Teleservices and Remote Medical Care System (TRMCS) case study [46], in which we examined how various features of the CADP tool suite can be used in an integrated fashion to analyze OMT diagrams via the LOTOS model generated from them according to Wang’s mapping rules [27]. In particular, we discuss test composition, exploration of paths that lead to deadlock, searching for patterns in the LTS graph, and refinement checking. (See [45, 46] for discussion of other analyses possible with LOTOS analysis tool suites.) 31 ‘4 '\ \“ Y A; ‘A ‘4.“ TRM CS Example The Teleseruices and Remote Medical Care System (TRMCS) is a distributed software system intended to offer access to a large volume of distributed patient data. At the most abstract level, the system should allow a user to browse a set of indices relevant to patient data in order to select the correct patient identity, retrieve a patient’s record based on such an identity key, and enter a diagnosis into the patient’s profile. The system-level object model, object functional model (OFM), and dynamic model shown in Figures 3.2, 3.3, and 3.4, respectively, depict the TRMCS at a high level of abstraction. (See Chapter 2, Section 2.1.1, page 11 for an overview of OMT diagram syntax.) In essence, the TRMCS waits for the user to select a patient identity key. After- wards, the user may continue to browse and select other keys, or may transmit the request for a patient’s record. If the patient profile is found, then it becomes available for entering a diagnosis. Otherwise, the user must select a new patient identity key. Figures 3.5 and 3.6 show the LOTOS model derived from the OMT diagrams in Fig- ures 3.2, 3.3, and 3.4 according to Wang’s formalization rules [27] (the specification has been split across two figures to comply with printing restrictions). Sorts and operations (lines 8-38, Figure 3.5) are derived from the object and object functional models, while processes (lines 40-77, Figure 3.6) reflect the behavior described in the dynamic model. TRMCS dataArchives: Data_Archives datalndices: Data_Indices Figure 3.2: System-level object model of the TRMCS 32 . . . .. ..x _ al.. n” ‘ hr S a.; flu. M. . m H. . .. ...... P. . .. . . .. f\ ..\ .ou It... P ‘ .L P \x. u .2 W \ . . .. a... at a: r\: .\v \ OI\ AK 4.... t C S Ry TRMCS r \ User_lnput m PatientJD Patient_Record Patient_ID Retrieve_Profile ll Diagnosis_Result Diagnosis_Request Diagnose_Patient ll Figure 3.3: System—level object functional model of the TRMCS TRMCS: t Retrieve_Profile(ptID: Patient_ID) [not(isValidPtID(ptID))] Select_Patient(ui: User_lnput) I / Select_Patient(ui) Browsing Select_Patient(ui: User_lnput) / Select_Patient(ui) Retrieve_Profile(ptID: Patient_ID) Sl tPt' t ':U It 6 6° _ a 16“ (“l ser— "P“ ) [isValidPtID(ptID)] / Retrieve_Profile(ptID) / Select_Patient(ui) Diagnose_Patient(diagreq: Diagnosis_Request) / Diagnose_Patient(diagreq) Figure 3.4: System-level dynamic model of the TRMCS 33 .,_ .5 . . .. .5. p». .. v. .2 . . a. S C .o. L. 4. ~.. .. . . Z ... a. g . «a» o. 9- up; :» i b 2. 5. d. ., ... n. .J .1. ya “4 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 specification TRMCS [Select_Patient, Retrieve_Profile, library Diagnose_Patient] (t : TRMCS) : noexit BOOLEAN endlib type TRMCS is Boolean SOI‘tS opns endtype Data_Archives, Data_Indices, User_lnput, Patient_ID, Patient_Record, Diagnosis_Request, Diagnosis_Result, TRMCS undef_Data_Archives : -> Data_Archives _eq_ : Data_Archives, Data_Archives -> 8001 undef_Data_Indices : -> Data_Indices _eq_ : Data_Indices, Data_Indices -> 8001 undef_User_Input : -> User_lnput _eq_ : User_Input, User_lnput -> 8001 undef_Patient_ID : -> Patient_ID _eq_ : Patient-ID, Patient-ID -> 8001 undef_Patient_Record : -> Patient_Record _eq_ : Patient_Record, Patient_Record -> 3001 undef_Diagnosis_Request : -> Diagnosis_Request _eq_ : Diagnosis_Request, Diagnosis_Request -> 8001 undef_Diagnosis_Result : -> Diagnosis_Resu1t _eq_ : Diagnosis_Resu1t, Diagnosis_Result -> 8001 undef_TRMCS : -> TRMCS _eq_ : TRMCS, TRMCS -> 8001 Select_Patient : User_lnput -> Patient_ID Retrieve_Profile : Patient_ID -> Patient_Record Diagnose-Patient : Diagnosis_Request -> Diagnosis_Result isValidPtID : Patient_ID -> 8001 isValidRec : Patient_Record -> 8001 make_TRMCS : Data_Archives, Data_Indices -> TRMCS getArchives : TRMCS -> Data_Archives getIndices : TRMCS -> Data_Indices Figure 3.5: High-level LOTOS model of the TRMCS, data part 34 45 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 67 68 69 70 71 72 73 74 75 76 behavior Select-Patient ? ui : User_Input; Select_Patient ! Select_Patient (ui); Browsing [Select_Patient, Retrieve_Profile, Diagnose_Patient] (t) where process Browsing [Select_Patient, Retrieve_Profile, Diagnose_Patient] (t : TRMCS) : noexit := Select_Patient ? ui : User_Input; Select_Patient ! Select_Patient (ui); Browsing [Select_Patient, Retrieve_Profile, Diagnose_Patient] (t) [] Betrieve_Profile ? ptID : Patient_ID; ( [isValidPtID (ptID)] -> Retrieve_Profile ! Retrieve_Profile (ptID); Diagnosing [Select_Patient, Retrieve_Profile, Diagnose_Patient] (t) [J [not (isValidPtID (ptID))] -> Browsing [Select_Patient, Retrieve_Profile, Diagnose_Patient] (t) ) endproc process Diagnosing [Select_Patient, Retrieve_Profile, Diagnose_Patient] (t : TRMCS) : noexit := Select_Patient ? ui : User_lnput; Select-Patient ! Select_Patient (ui); Browsing [Select_Patient, Retrieve_Profi1e, Diagnose_Patient] (t) [] Diagnose_Patient ? diagreq : Diagnosis_Request; Diagnose_Patient ! Diagnose_Patient (diagreq); Diagnosing [Select_Patient, Retrieve_Profile, Diagnose_Patient] (t) endproc endspec Figure 3.6: High-level LOTOS model of the TRMCS, behavior part 35 Test comp . . ._ VA. e“~"~-‘_." ".‘o A ‘ \ " U. , .“ 2‘ 7 ‘ ‘ . li.’ -" . .‘ “ . : I y. 'l _ .. ‘ " P 4 ,V ‘~.’_ "I ‘,i_ x. 3.; \' .A ., r. ‘ ._;\§_-| A -\ ‘ _rx“ s_.~ ‘ s ( i- . ,_V A .." "v ..\ F" .‘ 4‘ ‘ " 4“. ”o“ 'K‘a; a s‘ . .‘ “.‘G$-" s ‘ v Test composition. The simple test process we use (Figure 3.7) asks if two consec- utive patient selections and valid patient record retrievals can be made successfully. The reachability of a Success event (line 13 in Figure 3.7) in the behavior described by a test process composed with the LOTOS model of a system determines the out- come of a test. Figure 3.8 shows, in text-based format, the (successful) result of the test from Figure 3.7 composed with the LOTOS model from Figures 3.5 and 3.6. 1 process Test [Select_Patient, Retrieve_Profile, 2 Diagnose_Patient, Success] : noexit := 4 Select_Patient ! valid_User_Input; 5 Select_Patient ? ptID: Patient_ID; 6 Retrieve_Profile ! valid_Patient_ID; 7 Retrieve_Profile ? ptRec: Patient_Record; s ([isValidRec(ptRec)] -> 9 Select_Patient ! valid_User_Input; 10 Select_Patient ? ptID: Patient_ID; u Retrieve_Profile ! valid_Patient_ID; n Retrieve_Profile ? ptRec: Patient_Record; m ([isValidRec(ptRec)] -> Success; stop)) w endproc Figure 3.7: Test for high-level TRMCS model Tests may be repeated after refinement to ensure that the system still performs de- sired behaviors. After refinement (refined OMT diagrams for the TRMCS are included for reference in Appendix B, page 236), the LOTOS model derived for the TRMCS is composed with a revised test process updated to reflect constants LANSING and DETROIT denoting specific Data Repository instantiations. The two val id-Pat ient-ID constants (lines 6 and 11 in Figure 3.7) are replaced with tuples Patient-ID (LANSING , valid-Query_Request) and Patient_ID(DETRDIT, valid-Query_Request), intro— 36 . ‘f‘ .4- fu—fi IV --~ \ P ,. "pg—~- \- I." ~—~ Ir. pf‘..- \- n0, 3,-- .g '—~-< . hun- “’ A~.‘ A 'I-"' 4 III- ' I“, a~ol 4' "a”.' .. c- I ‘0, 5-... 'P ran.— - \- I .v'. 3.....- I. f-..- F In. II .u‘. .~.. .'~, "~.“ ‘ u- .- ’ ‘.~.. ‘ ~"‘\~v—- II ‘ .- ,-, ~vv-~ l‘- .‘ r ' Ie a..A , V .. 7 1 o v A "' . . ‘ n. ‘2 I L -y., i u.“ ‘ l.‘ I ', v ‘ '\ . ' s , .. .‘g" 7‘ . ~. .‘i v . ‘ a 4 V .4 r: ‘ 7, A *- .. u~, v a l"- l i 0 . r ' k-‘ _“. F‘ ¢¢.' - '~ ~.. .9 \ , .I t; ‘V 6 N EI‘ L'v .¢. 1" t.. A . ‘ ~ v M“ A ‘ -. n. .. z '1‘ . .1 \ ‘7 e “\ b, ,. L‘ ‘ y ’ a‘ ““M des (O, 9, 10) (0, "SELECT_PATIENT lVALID_USER_INPUT", 1) (1, "SELECT_PATIENT lVALID_PATIENT_ID", 2) (2, "RETRIEVE_PRUFILE !VALID_PATIENT_ID", 3) (3, "RETRIEVE_PROFILE !VALID_PATIENT_RECORD", 4) (4, "SELECT_PATIENT !VALID_USER_INPUT", 5) (5, "SELECT_PATIENT !VALID_PATIENT_ID", 6) (5, "RETRIEVE_PROFILE IVALID_PATIENT_ID", 7) (7, "RETRIEVE_PROFILE lVALID_PATIENT_RECORD", 8) (8, SUCCESS, 9) Figure 3.8: Results of high-level TRMCS model under test duced during refinement of the high-level TRMCS Retrieve Profile service (see [46] for details or Appendix B for an overview of this service refinement). Thus the re- vised test asks if it is possible to query the LANSING Data Repository, receive a valid patient record, and then query the DETROIT Data Repository, also receiving a valid patient record in response. If all paths lead to success, then we can say that the orig- inal high-level LOTOS model (derived from the original OMT diagrams modeling the system) and the more detailed refinement LOTOS model (derived from refined diagrams) are testing equivalent (with respect to this simple test). Information regarding the results of the refined model under test is shown in Figure 3.9. CADP indicates six deadlock states (i.e., sinks) in the resulting LTS graph.3 By examining the labeled arcs leading to these deadlock states, we determine that only the paths ending at states 185 and 186 are successful (i.e., terminate with arcs labeled with the Success event). Paths ending at any of the other deadlock states represent the test’s failure; that is, either the first query (LANSING) results in an undefined patient record, or the first query passes but the second query (DETROIT) 3CADP uniquely numbers the nodes in an LTS graph. 37 ' \ IF i. . ... ~ -6 O " v . n'v ll ’ \ A. o. \ . C .V:'-p~,.~ Ucflvmcui '— CA" .A .5'. .§‘ -‘ v .. .. . ‘ r‘ . “ LF‘ _‘ . .."\ \" _. ~. N ’t .7 \' V i r O g 5.“ ._l‘4‘o . ‘ a -“ ’- . ‘ I $ .‘ ‘ ~ L. \‘fi!._ ‘ 6, c . s ‘. o ‘ . ‘ n v “ " ~, I ‘ ‘g- x . A. T L l — ‘ a \ ..I \ \‘z‘ » ‘ ‘ §‘ . \_\ _\ ‘ 7 ‘ ~ results in an undefined patient record. Thus the original model and its refinement are not testing equivalent with respect to the consecutive query test. refined_trmcs.aut: 187 states, 282 transitions , 6 taus transitions 27 distinct labels Branching factor : 1.50802 refined_trmcs.aut is deterministic 120 122 123 173 185 186 are deadlock states Figure 3.9: Information about refined TRMCS model under test Paths leading to deadlock. Further investigation is warranted to determine the nature of the failed queries. CADP offers several options for eliciting examples of such queries. The most straightforward one simply explores the LTS graph and finds the shortest path from the initial state to a given state, in this case one of the deadlock states 120, 122, 123, or 173 listed in Figure 3.9 (recall that paths ending at deadlock states 185 and 186 are successful). The shortest path gives the developer a minimal example depicting a problem. Ideally the developer will gain insight into the nature of the problem either by examining the example itself or by stepping through the example with interactive simulation. Figure 3.10 shows the shortest path to state 120, indicating that the first Retrieve Profile query (LANSING) results in an undefined patient record. Similar results are obtained for states 122 and 123, while the shortest path to state 173 reveals a path where the first query passes but the second query (DETROIT) results in an undefined patient record. 38 lav-v nnv. \- u 1" Una-rav- h “:Iv-v: . I \ob, oa._.~-- "" a“: '- u .1. ‘ V U. "0 huts---— .‘ I. _ Xv .w..|.- "" qR'Ou—‘.- id .I ‘ "4' I v: V 0" u‘f-s..__~ RR- C-‘-~ I- ‘uv, ._....l ..oa 'i.“‘- In. a l...‘! ‘N-Qah- \ '~ .V . "\‘ 9, -“ \ ~‘ ' --.v‘ Q. .. ‘ ‘ ' V. W . ‘5-A. I ' .. 8 ~:"".".'- .A "V ‘ ‘ r. . try I ‘ . h» ’ 4 ‘A V W D. ‘ l . . KN”: '. r i i. k‘w M. .-‘ M \ . ‘\ > ‘3 t-AY‘V. - I I u.) ‘r , t. { .;." ~ ‘v ,. ‘AQL. 'J ;" ‘§ ‘C g‘." -., (T ,‘, ‘\"_ ‘ l ' .1, f.. I -.._, ' “ A ‘ ‘.‘ K. ..‘ u- S K - e Tea“, ~‘ . 9"”:‘A \ des (O, 12, 121) (0,"SELECT_PATIENT lVALID_USER_INPUT",1) (1,NAME_MDNITOR_GETTABLE,6) (6,"SELECT_PATIENT lSELECT_PATIENT (VALID_USER_INPUT, DATAINDICESLIST)",15) (15,"NAME_MONITOR_GETTABLE lEMPTY",32) (32,"NAME_MUNITOR_REGISTER lDETROIT l5678",53) (53,"RETRIEVE_PROFILE lTUPLE_PATIENT_ID (LANSING, VALID_QUERY_REQUEST)",63) (63,"CLIENT_QUERY lLANSING lVALID_QUERY_REQUEST",75) (75,NAME_MONITOR_GETTABLE,84) (84,"NAME_MONITDR_GETTABLE lINSERT (EMPTY, DETROIT, 5678)",91) (91,"NAME_MONITDR_REGISTER lLANSING l1234",99) (99,"CLIENT_QUERY lUNDEF_QUERY_RESULT",110) (110,"RETRIEVE_FROFILE lUNDEF_PATIENT_RECURD",120) Figure 3.10: Example of shortest path to state 120 in refined TRMCS model under test Searching for patterns. Initial examination of these four shortest path examples suggests that failed queries can be attributed to the timing of Data Repository regis- tration. That is, if the Client attempts to query a Data Repository before that Data Repository has registered with the Name Monitor, then the Client will not be able to make the connection and must return an undefined patient record. To further con- firm our suspicions, we may use another CADP feature that allows us to search for patterns in the LTS graph. In this case, we are interested in paths leading to the return of an undefined patient record in response to a query (this pattern is shown in Figure 3.11). Either breadth-first or depth-first search may be used; we opt for depth-first search and obtain 43 examples at varying depths, only 14 of which pass the first query (i.e., receiving a valid patient record from the LANSING Data Repository). One such example is shown in Figure 3.12. Examining these additional paths leads us to conclude that the undefined patient records are indeed the result of a delayed Data Repository registration with the Name Monitor. 39 - . .~Q.Q-~. - !\-:U- v-“‘-v- ~‘.l—A~-O."I- . "'33": VA""- -IAQ‘_~-.‘~'~.- ‘ . ‘K “ .) ‘ - . K -J A [SELECT_PATIENT !VALID.*] [RETRIEVE_PROFILE !UNDEF.*] Figure 3.11: Pattern: undefined patient records in response to valid queries *** sequence found at depth 25 "SELECT_PATIENT !VALID_USER_INPUT" "SELECT_PATIENT !SELECT_PATIENT (VALID_USER_INPUT, DATAINDICESLIST)" "RETRIEVE_PROFILE !TUPLE_PATIENT_ID (LANSING, VALID_QUERY_REQUEST)" "NAME_MONITOR_GETTABLE" "NAME_MONITOR_GETTABLE !EMPTY" "NAME_MONITOR_REGISTER !LANSING !1234" "CLIENT_QUERY !LANSING !VALID_QUERY_REQUEST" "NAME_MONITOR-GETTABLE" "NAME_MONITOR_GETTABLE !INSERT (EMPTY, LANSING, 1234)" "DATA_REPOSITORY_SEARCH !VALID_QUERY_REQUEST !1234" "DATA_REPOSITORY_31234 !VALID_QUERY_REQUEST !1234" "i" (i) "DATA_REPOSITORY_Sl234 !VALID_QUERY_RESULT" "DATA_REPOSITORY_SEARCH !VALID_QUERY_RESULT" "CLIENT_QUERY !VALID_QUERY_RESULT" "RETRIEVE_PROFILE !VALID_PATIENT_RECORD" "SELECT_PATIENT !VALID_USER_INPUT" "SELECT_PATIENT !SELECT_PATIENT (VALID_USER_INPUT, DATAINDICESLIST)" "RETRIEVE_PROFILE !TUPLE_PATIENT_ID (DETROIT, VALID_QUERY_REQUEST)" "CLIENT_QUERY !DETROIT !VALID_QUERY_REQUEST" "NAME_MONITOR_GETTABLE" "NAME_MONITOR-GETTABLE !INSERT (EMPTY, LANSING, 1234)" "NAME_MONITOR-REGISTER !DETROIT !5678" "CLIENT_QUERY !UNDEF_QUERY_RESULT" "RETRIEVE_PROFILE !UNDEF_PATIENT_RECORD" Figure 3.12: Failure on second query (DETROIT) in refined TRMCS model under test 4O Refinel .-“ .. . O .c O .k us. . . . . ,\.. .. A i n: . u! - 4 l...“ o ‘7. 1~.. v . Q1! .. A _. l. I _I . a F... . u... . .. .i O a ”I. ‘ \ o v .\ ~ a Q 1 ; K ' ~ r . {fl Refinement checking. If the methods previously described do not yield conclu- sive results, then CADP offers an automated way to check refinement by comparing the LTS graphs of a model before and after refinement. Several bisimulation equiv- alences [61, 73] are available, as well as observational [73] and safety relations [74]. The comparisons offer a diagnostic counterexample at the first indication that the LTSs differ. For illustrative purposes we compare the model under test before and after refinement, subject to minimization under the safety relation and hiding of the aggregate objects’ services (to make the LTS graphs amenable to visual inspection). By visually comparing the LTS graphs in Figure 3.13 (the high-level LOTOS model derived from the original OMT diagrams, under test) and Figure 3.14 (the LOTOS model derived from the refined OMT diagrams, under test), we immediately see that the refined model has two opportunities to fail the test (in Figure 3.14, the arcs from node 4 and node 7 to node 9). The high-level model (Figure 3.13) treats the Retrieve Profile service as a function, so that valid queries (arcs from node 2 to node 3 and from node 6 to node 7) always result in valid patient records (arcs from node 3 to node 4 and from node 7 to node 8). However, the refined model realizes the high-level Retrieve Profile service as a collaboration of aggregate objects’ services. If we attribute the failed queries to the nature of distributed computation, that is, the possibility in our model that the Client may pose a query before the desired Data Repository has registered, then, in this context, the refined TRMCS realizes the Retrieve Profile service transparently. If, however, the system requires that all Data Repositories be online and accessible all the time, then the current design is not satisfactory. 3.1.3 Analysis Tool Output Overall, CADP has much more user-friendly output than TOPO/ LOLA. During the case studies [45, 46], we were able to output both text-based paths through the LTS 41 SELECT_PATIENT !VALID_USER_INPUT SELECT_PATIENT !VALID_PATIENT_ID RETRIEVE_PROFILE lVALID_PATIENT_lD RETRlEVE_PROFILE !VALID_PATIENT_RECORD SELECT_PATIENT !VALID__USER_INPUT SELECT_PATIENT !VALID_PATIENT_ID RETRIEVE_PROFILE !VALID_PATIENT_ID RETRIEVE_PROFILE !VALID_PATIENT_RECORD SUCCESS Figure 3.13: Original TRMCS model under test 42 \ ELECT_PATIENT !VALID_USER_INPUT s ELECT_PATIENT !SELECT_PATIENT ( VALID_USER_INPUT, DATAINDICESLIST ) l' TRIEVE_PROFILE !TUPLE_PATIENT_ID ( LANSING. VALID_QUERY_REQUEST ) RETRIEVE_PROFILE !VALID_PATIENT_RECORD ELECT_PATIEN T !VALID_USER_INPUT § ELECT_PATIENT !SELECT_PATIENT ( VALID_USER_INPUT. DATAINDICESLIST ) I' ETRIEVE_PROFILE !TUPLE_PATIENT_ID ( DETROIT, VALID_QUERY__REQUEST ) RETRIEVE_PROFILE !VALID_PATIENT_RECORD RETRIEVE_PROFILE !UNDEF_PATIENT_RECORD SUCCESS RETRIEVE_PROFILE !UNDEF_PATIENT_RECORD Figure 3.14: Refined TRMCS model under test, safety-reduced 43 b .‘ I A . ‘ . ; “A4 A ... ." I' . , . ‘ --.. U .A-.- .. . V. H ... P s .. .f a. _-' on '- v- ‘ ~~ ‘1 7C" ... .. ‘ s- ..‘ C, V . ‘A ,h \ lQ . ‘ § ‘5 r“ l ‘0 V. A “ y a" ‘ i b n graph matching certain criteria (such as the shortest path to a particular state or matching a given pattern of actions), and graphical depictions of minimized LTS graphs (a feature not available in TOPO / LOLA). CADP’S graphical depiction of an LTS graph can act as a “road map” for simulations and facilitate understanding of failed test cases (Figure 3.14), while its text—based output is easily read by humans. On the other hand, TOPO/LOLA’S cryptic text-based output informs the de- veloper that deadlocks exist, but makes the developer search for the deadlocks in a cumbersome log file and manually back-trace the sequence of actions that led to them. For example, in [45] TOPO / LOLA found four deadlocks in initial refinements of the requirements model for ENFORMS [71] that, after examining the log file (see Figure 3.15 for excerpts), we attributed to the Client being unable to submit a query with an undefined address. We first had to search the log file for the keyword stop, indicating a deadlock, and then manually back-trace each process’s instantiation to figure out the sequence of actions leading to the deadlock. Adding a guarding condi- tion to the dynamic model of the Client to check for undefined Archive Server addresses resolved these deadlocks. 3.2 Lessons Learned In addition to the highlights, we learned two lessons from these case studies [45, 46] that have motivated our later work with McUmber’s UML-to-Promela formaliza- tion [31] and the Spin [69] analysis tools. First, structural analyses (i.e., diagram consistency checking) should be performed prior to formal model generation because formal model analysis tools do not always detect diagram inconsistencies. Second, in order to be useful, analysis results should be related back to the diagrams. This section briefly overviews these lessons and how they have affected our later work. 44 -_—_.. __ _ process duplicate3 [format_request,retrieve_data,analyze_data,client_query, name-server-gettable,archive_server-query,name_server_register, archive_server_q4899,archive_server_q5699] : noexit := name_server_register ! storet ! 5699; stop endproc process duplicate4 [format_request,retrieve_data,analyze_data,client_query, name_server_gettable,archive_server_query,name_server_register, archive_server_q4899,archive_server_q5699] : noexit := name_server_register ! pcs ! 4899; stop endproc process duplicate9 [format,request,retrieve_data,analyze_data,c1ient_query, name_server_gettable,archive_server_query,name_server_register, archive_server_q4899,archive_server_q5699] (rr_92:retrieve_request) : noexit := archive_server_query ! retreq_getqueryrequest(rr-92) ! undef_address; stop endproc process duplicate17 [format_request,retrieve_data,analyze_data,client_query, name_server_gettab1e,archive_server_query,name_server_register, archive_server_q4899,archive-server_q5699] (rr_92:retrieve_request) : noexit := archive_server_query ! retreq_getqueryrequest(rr_92) ! undef_address; stop endproc Figure 3.15: TOPO / LOLA log file indicating deadlock in ENFORMS 45 o. - ,. \ o. . 09 v . ‘ \ " . ‘A A..- _ v ‘ *. 1». V._- ‘ ‘ D‘- V‘ " »- n- s . '7‘ ' v . ' ’I -...._~ . n I. ‘ o. .. . g, §\_ 1 “c I' A . 5‘ . ' kn ’ r .t.‘ r . v~. . .. ‘ " 'u..‘ 0‘ . _ .‘ . i.‘ ‘u .- g... ' v \ ' 9.- V . k s.. 6 A ,y . ‘- Structum ‘ 7 '7’ .4. .- ' A‘ -- y. - . . FOCUS :- u.‘o ' pr.‘ \ 4| . x .. ">’\\ 4‘ b ‘p b ‘- _ _ Q~ . §_ _ 0-— '< _ .k \ 4 . .‘E. ..“.~. - .A w \ ‘.._ J \ A.‘ . ‘4 4.".- .-.\. N . {_“fl '3. . '- ‘ lo! . . '“A. . - ‘ Vs .‘ _.“(‘..‘ ‘i _ '(‘.. ‘ ‘41- ”‘3. . ‘ s. 94“) ‘V ‘A -;‘ l .. “ l1\ 'v,. " A. A '7“ 1' “I? . . . 5‘") I I A". I" ‘I l 1“. t. ' ._ v s \“ 7’ I“ (1‘ . “‘4.’-"~ ‘ 9 \ w.- p; '. (.F‘ .‘Al‘y‘ Structural Analysis of Diagrams. In [45], in order to validate Wang’s ap- proach [27] we applied Wang’s mapping rules to object-oriented diagrams for EN- FORMS [71]. During this process, we discovered (by visual inspection), but did not at first correct, several diagram inconsistencies. In many cases, the signature of a given message send in one state diagram did not match the signature of a corresponding event, the given message’s reception, in another state diagram (e.g., parameters were transposed, etc). However, we found that the TOPO analysis tool was incapable of detecting these errors in the resulting formal model (i.e., syntax and semantics checking passed). In Wang’s formalization of OMT diagrams into full LOTOS models [27], a mes- sage, possibly with parameters, from the state diagram of a sender object is received by a target object as an event on a transition in the target object’s state diagram. The variables in the event’s parameter list (representing attributes of the target object) take on the values passed in the message. An example of inconsistent state diagrams is shown in Figure 3.16. The diagrams are inconsistent because the signature for message foo’s reception on the transition in Object B’s state diagram differs from the signature for sending message foo to Object B on the transition in Object A’s state diagram (:1: is an Int and y is a String). However, in terms of LOTOS, which does not require that processes must synchronize, there is nothing syntactically or semantically wrong with the model fragments shown in Figure 3.17 derived from the diagrams in Figure 3.16, even though the processes will not synchronize and exchange data as intended. This example underscores the motivation for consistency checking at the diagram level, as well as for automated instead of manual translation of diagrams to models. Consistency checking at the diagram level is necessary to detect inconsistencies that might otherwise pass target language syntax and semantics checking and introduce subtle errors into the model. Chapter 5 discusses how we use this approach in our 46 Object_A Ob’w—A A . x: 1m State_A1\ Oblw-B'foo(x‘ y) >( State_A2 y: String / L Object_B Ob‘ICa‘B 2: String j k Figure 3.16: Inconsistent OMT state diagrams processA (sender) : foo ! x ! y; processB(receiver) : foo ? 2: String ? w: Int; Figure 3.17: LOTOS model fragments from inconsistent diagrams 47 ‘ v v ‘V‘W: ‘ -.A’ h. I n P h v o ‘ ‘- mkhs. - A . V._ O, . l l\ 'l . hh.‘A. L a)‘ U v. .. .,. . . '4 .3. . A _ y—u-a ‘ \ ~V - 5 hits» i... ‘ .u' . \ a ' "~ \c... . . . , 1 A ‘ v o—A... l“\ ' I. I. i‘ t a to. I A ‘-.‘~ 0 ‘K ' ‘ i . .. l ‘ .._‘ ' I .V u. ‘ .\ V “‘4' -1 “1 g . ‘- -,. _ . “-A‘ . ‘9 \ “I -f . all . 7‘... 'A.. ‘i work with McUmber’s UML-to—Promela formalization [31]. Visualization of Analysis Results in Terms of Diagrams. Our experiences demonstrate that the visualized LTS graph produced by CADP can act as a “road map” for simulations and facilitate understanding of failed test cases, much more so than TOPO/LOLA’S cryptic text—based output. However, Wang’s formalization does not include information other than event names and parameters on are labels in the LTS, and thus analysis results cannot be automatically mapped back to state diagrams (the same event may appear on multiple transitions so a simple name lookup scheme fails). Instead, the developer must infer the relationship between the analysis results, including the visualized graph, and the original diagrams, based in part on knowledge of Wang’s mapping rules. One approach to this problem is to push diagram-specific knowledge into the formal model so that such information can be recovered from analyses of the formal model. Chapter 6 discusses how we use this approach in our work with McUmber’s UML-to-Promela formalization [31]. 48 Chapter 4 Model Development and Analysis: Framework and Process This chapter describes a model development and analysis framework that addresses model creation, model analysis, and model refinement based on analysis results. This framework extends the formal model generator architecture suggested by Wang’s [27] and McUmber’s [31] approaches, including well-formedness checks and visual feedback to diagrams (Chapter 3, Section 3.2). To provide context for the following chapters, we instantiate this framework with concrete tools that support McUmber’s UML-to- Promela mapping rules [31], and describe a model development and analysis process that pertains to this instantiation of the framework. This process encapsulates the steps of model creation, model analysis, and model refinement, and it serves as a roadmap for the analyses discussed in Chapter 5 and the visualizations of analysis results discussed in Chapter 6. Formal Model Generator Architecture. Both Wang’s [27] and McUmber’s [31] approaches suggest an architecture similar to what is shown in Figure 4.1 to real- ize a formal model generator based on mapping rules from a (source) semi-formal 49 o \ O - l ' l V P" '- ' no; A b A ‘ . r . r9 . , .. . a .n. . . .. .- ' V ‘ "V ‘ ‘ . i-‘llob‘lh‘ ‘._ .. . . '9-.. \'~’ a ,- . ‘ ‘~ .A‘ ‘ A ‘ n R i \‘ r 0 \-~. g. ll ‘ ‘~ 3. T A 41; 4 U. A. 7 s A a., h . \ " -( - ll "' _ " 'n- ‘- ._ - V v .. 4- "- ‘ \ ‘\’ .‘ ‘1 ‘s: o, . u “'7 I H i “ o "~~ t, ‘h \ ‘l r, ~_ -7‘ . \ \.. \J' "t. . . . H“ 5“ . ..“.. fi..v ‘ a. a .‘ \- "0.\, a ‘. a ‘7‘. v ‘k‘ .- - ‘~ ‘5 i‘ -\ “a . - s a. * L ‘5 a 1 Each mapping approach uses a graphical language to a (target) formal language. notation (e. 9., OMT, UML) as the semi-formal language, which implies the use of a Graphical Editor for that particular notation. The user draws graphical diagrams for an object—oriented system based on (prose) requirements. A Translator that incorporates knowledge of the mapping rules from a given graphical notation to a particular formal language (e. 9., OMT-to—LOTOS, UML-to-Promela) generates the formal model corresponding to the (intermediate representation of) graphical dia- grams drawn by the user. Together, the Graphical Editor and Translator realize a formal model generator. However, formal model generation is not an end in itself. As shown in Figure 4.1, the user then performs analyses on a generated formal model with appropriate Formal Language Analysis Tools (e.g., TOPO/ LOLA, Spin). Such tools may require interaction from the user, as illustrated by the “commands” data flow. If the formal language allows, the user may optionally supply properties (as indicated by the dashed arcs in Figure 4.1) for the formal language analysis tool(s) to check against the formal model (e. 9., a test process to compose with a LOTOS model, an LTL property to check against a Promela model). As indicated by the dash-dotted arc in Figure 4.1, the user must interpret (raw) analysis results obtained from the formal language analysis tool(s). Problems with Suggested Architecture. Both approaches assume the well- formedness of diagrams, including diagram integration constraints. Therefore, neither addresses the problems that ensue from attempting to generate formal models from ill-formed diagrams, other than expecting that syntax/semantics checking or other analyses provided by formal language analysis tool(s) will detect such errors at the formal model level. However, as discussed in Chapter 3, some diagram ill-formedness errors are not readily detectable at the formal model level. Additionally, as represented by the dash-dotted arc in Figure 4.1, both approaches 1Appendix C illustrates the architectures realized in these approaches. 50 Prose requirements commands User input for graphical diagram(s) Graphical Editor Intermediate representation l of diagram(s) r Translator Mapping rules for formal language Formal Language Analysis Tool(s) I Analysis results (raw) I ...................................... i L Formal Model Generation: Output graphical diagram(s) to intermediate representation, and generate formal model according to mapping rules. Formal Model Analysis: Perform syntax and semantics checks on formal model, and perform tool-specific analyses such as simulation or model checking. Figure 4.1: Suggested architecture for a formal model generator 51 expect the user to interpret raw analysis results emanating from formal language analysis tool(s). As noted in Chapter 3, sometimes these results are quite cryptic. No mechanism is provided for relating analysis results back to the original diagrams in order to guide diagram refinement. Model Development and Analysis Framework. Our model development and analysis framework, shown in Figure 4.2, extends the formal model generator archi— tecture from Figure 4.1 in two ways. First, although we still split the task of analysis into two parts, structural and behavioral, we apply structural analyses to the di- agrams (i.e., prior to formal model generation) to ensure intra- and inter-diagram consistency, thus placing this burden on tools that are more suited to the task than formal language analysis tools. Formal language analysis tools then perform behav- ioral analyses on formal models generated from well-formed diagrams. Second, as represented by the bold arcs to the Graphical Editor & Visual- ization Environment oval in Figure 4.2, results from both types of analyses are visualized in terms of graphical diagrams. Structural analyses are visualized in terms of the original diagrams in order for the user to locate and correct diagram inconsis- tencies. Raw analysis results from behavioral analyses are processed by an Analysis Result Processor (shown as a bold oval) and then visualized in terms of either the original diagrams or complementary ones, thus relating analysis results from the for- mal model level back to the diagram level to guide diagram refinements. (Raw analysis results from behavioral analyses may also be processed into a human-readable report to complement visualizations, as represented by the bold dash-dotted arc to the User oval in Figure 4.2.) Therefore the graphical editor of Figure 4.1 becomes a Graphical Editor & Visualization Environment (shown as a bold oval in Figure 4.2). While current work [40, 41, 42, 53] has focused on a subset of the UML graphical notation appropriate to embedded systems, generated Promela models (according to 52 McUmber’s UML-to—Promela mapping rules [31]), and the Promela analysis tools of Spin [69], future work may include extending the framework in a third dimension to incorporate other formal languages and tools, such as SMV2 [75]. User input for graphical diagram(s) Structural Analysis: Graphical Editor Perform intra- and inter- & Visualization Prose requrrements Environment diagram consistency checks prior to formal model Intermediate generation. representation r of diagram(s) Translator Formal Model Generation: ’ Output graphical diagram(s) User Mapping rules to intermediate representation, for formal language and generate formal model according to mapping rules. commands Formal model Formal Model Analysis y (Behavnoral Analysrs): l I Perform syntax and semantics Properties ------ F0 . guage checks on formal model, and Analysrs Tool(s) . perform tool-specr fie analyses such as simulation or model checking. Analysis results (raw) Analysis results (human-readable) Analysis Result Processor Convert raw analysis results l! into human-readable reports or visualization instnictions. _] Analysis Result Processing: Figure 4.2: Model development and analysis framework Instantiated Framework. The formalization of UML enables various types of analyses of the UML diagrams and corresponding formal model of an ob ject-oriented software system, depending on the mapping rules given and the formal language anal- ysis tools(s) available for the chosen target formal language. To provide the context 2Symbolic Model Verifier 53 for the following chapters, we first instantiate the model development and analysis framework with concrete tools that support McUmber’s UML-to-Promela mapping rules [31]. Based on this instantiation, we then describe an iterative and incremental model development and analysis process to create, analyze, and refine (formalized) UML diagrams. This process serves as a roadmap for subsequent chapters. Figure 4.3 refines the framework from Figure 4.2, instantiating the Graphical Editor & Visualization Environment with our (UML) tool MINERVA [40, 47, 50, 51, 52], and the Translator with McUmber’s tool Hydra [31, 48] that incorporates his UML-to—Promela mapping rules [31]. Parts A and B, respectively, indicate that MINERVA and Hydra can be used cooperatively both to perform structural analyses on UML (class and state) diagrams drawn by the user, and to generate formal models in a (supported) target language (in this case, Promela). The user performs behavioral analyses of generated Promela models with Spin [69] (Part C), which instantiates the Formal Language Analysis Tool(s) process oval of Figure 4.2. If using Spin in model-checking mode, the user may supply Spin with an LTL property (Part D) to check against the Promela model. As indicated by the dashed arc in Figure 4.3, we recommend but do not require the use of Dwyer et al.’s speci- fication patterns [43] to guide the creation of LTL properties [40, 41, 42, 53]. We have found the specification pattern taxonomy to be useful when attempting to write formal properties based on English natural language requirements (see Chapter 2, Section 2.2.4 for a brief overview of specification patterns). Finally, as represented by the bold arcs from MINERVA, Hydra, and Spin to MIN- ERVA in Part E, a combination of plug-in functions within MINERVA and a collection of Perl scripts handle the responsibilities of the Analysis Result Processor from Figure 4.2. 54 Prose requirements it Hydra Mapping rules for Promela commands _. Promela model Specification patterns 7 Spin _ Model 7 checking Figure 4.3: Framework from Figure 4.2 instantiated with tools properties _J. 55 Model Deve 313; print“ - ‘ Model Development and Analysis Process. The model development and anal- ysis process is iterative and incremental. As shown in the process flow diagram in Figure 4.4, in Step A, the user begins by drawing UML diagrams in MINERVA’S graph- ical editors for the class and state diagrams. The class diagram is required, and then additional state diagrams may be associated with individual classes. Assuming no errors are introduced at the diagram level, in Step C MINERVA produces an intermedi- ate representation of the diagrams, and in Step E, Hydra translates the intermediate representation into a Promela model (according to UML-to-Promela mapping rules). Spin can then be used either in simulation mode (Step F) to explore behavior such as requirements or usage scenarios, or in model checking mode (Step G) to check requirements-based properties. Steps B and D shown as bold rectangles (and Feedback lines 1 and 2 shown as bold dotted arcs) in Figure 4.4 were not present in Wang’s and McUmber’s approaches. In general, it was left to the formal model analysis tool(s) to detect syntax and semantics errors at the formal model level with no direct feedback to the diagrams to indicate the source of the errors. We argue that diagram inconsistencies are better detected, and visual feedback of these errors is more easily achieved, at the diagram level (that is, prior to formal model generation). Chapter 5, Section 5.1, describes the structural analyses available. Discussion of how visual feedback from structural analyses (Feedback lines I and 2) is accomplished is deferred until Chapter 6. Analysis feedback support as depicted by Feedback lines 3 and 4, shown as bold dotted arcs in Figure 4.4, were also not available in Wang’s and McUmber’s ap— proaches. Chapter 5, Section 5.2, discusses the behavioral analyses afforded by Spin, namely simulation and model checking. In Chapter 6 we show how both UML model simulation and simulation of counterexamples3 with Spin (Steps F and H, respec- tively) can produce trace data that can be displayed directly in the context of the 3A counterexample produced by the Spin model checker can be retraced with Spin in guided simulation mode in order to produce trace output, normally suppressed in model checking mode. 56 2.3... 2:35....» I..7.>_...:< _....::.:..:.f. A~...I.J TJ=J= -...iii e. .._.7..,.:..:< :..::.:..:..: moons»; 8 E5383 8 «:30 333538 4. m "......I..'......'I....'.'...I.I.I.."..I'..'.'I.."'.I.AUJ." " n I a I I I u I I.."".III..........II'IIII'I"D I n a u 2. u I I .llllllvll I I T Ir. .LI m u 1 m a a .. a C a S 1m. ..I.. as; s g H .c a . m ( .. . t m , m . m a. d m C C 3 c t c o a m .m n e n d m m m. a c m Wu g C ..w 0 ..n mld .m .IU. 6 O pf». M c .w .m g .n... C t m m m. t e m d d H mm m C m .l g .K m t. J1» S C V iS. V ml» 0 V .m l gum S d C V 0 m hm m a .m e. w m m m ..n. c m w C S C t m e ( C m e a )) m u n. m mew 1 ..Ia 2. (Ix C nnU. .m n mu 0 .m m H aw M S ( a a a a a la a _ _ . _ _ <5ng scan 25 AEEwaE a £533 GEE—wan. cooanonv _ llllllllllllllllll _ 20>": ESwEE 29o— EpoE 38.5: 89:95. _annbm meg—«Ea. _Sogfiom Figure 4.4: Iterative and incremental model development and analysis process 57 ‘| ‘. ‘v . 4'. a L‘s“... “‘5 .... . .... ..i 'l A. diagrams using MINERVA (Feedback lines 3 and 4) to aid in the debugging and re- finement of the UML diagrams. 58 Chapter 5 Analyses This chapter discusses the types of analyses enabled by the formalization of semi— formal object—oriented graphical modeling notations such as OMT or UML. For il- lustration purposes, we focus primarily on the analyses enabled by McUmber’s [31] formalization of UML diagrams with Promela, the input language for the analysis tool Spin [69]; thus, the model development and analysis process described in Chapter 4 for use with the model development and analysis framework instantiated in Chapter 4 is reproduced in Figure 5.1 for convenience to the reader. This chapter discusses the bolded and dash-dotted boxes in the process flow diagram. As shown in Figure 5.1, analyses are divided into two categories, structural and behavioral. (Structural analyses are indicated with bolded boxes, and behavioral analyses are indicated with dash-dotted boxes.) Structural analyses, discussed in Section 5.1, pertain to intra- and inter-diagram consistency checking with respect to several criteria, while behavioral analyses available, discussed in Section 5.2, depend on the target formal language and formal language analysis tool(s) chosen. For exam- ple, as shown in Figure 5.1, McUmber’s UML-to-Promela formalization [31] affords both simulation (Step F) and model checking (Step G) capabilities via Spin [69]. In contrast, as discussed in Chapter 3 and [45, 46], Wang’s OMT-to—LOTOS formaliza- 59 ._.~J..— _—._ .-:.....‘ :.7>._._.:< ...::..::r. z.7.£...2<. t..::.1..:;: (A) I I | I Draw/refine model: A I I (1) Class diagram E (2) State diagram(s) I E < I ’ 5? Z I v I '0 l 7 7 w I z I [(8) Pre-processing checks 1 g c: '5': a “>’ ’ 'E ' I g 2 I V l (C) _. 5 I l Output intermediate '11 g 3,, l I representation g .... cu ‘éé I " i ’73 I I - ’ ’ 8 "‘ 9: I g l (D) Intermediate checks l—24 (g I E e I l E l 'O '9. | 3 t: 8 | 333 I} I (E) Generate target language 0; .... formal model 51 l o | a _ '3 _ a :n l a l- rl-l-l-I-I- -l-I-I-l-III a I i(F) Simulate model ' 3 IE: 8 55 - (and generate trace data) ' as I !-l-I-I-I-l-I-I-l-l-l-! “’ Z I o -I‘LO-l-l-I-l-I-l-I-I-l 5“ 8 E l “6) Model check ro rties ! u§§ m I II-O-l-l-l-O-Ip-Ip:0-l-I-! > a E I l o o -I-l-I-I-l I-l-I-l-I-l m t I I I Simulate counterexample i 4 l i l (and generate trace data) i Figure 5.1: Iterative and incremental model development and analysis process, reprised from Figure 4.4. Bold boxes (A, B, D) represent structural analyses; dash- dotted boxes (F, G, H) represent behavioral analyses. 60 _ . .Lll rpm, "r” "r - k..‘,u"t.u:. ' .(1 ‘ I x'w o . _- V ‘ ~ A, . . ., . . C a ._ . i‘- “l I " r \ \aa. ‘ u .-.,.‘... u y .'I u M... .~..i . A. ‘ p I 4 . ‘ I\‘ -,._ V 'y.. ‘ h... ._‘ ‘ I ‘V V . .‘V-‘F‘ j? 'V: v ‘ “ 44..., "--., P 1". 7') ‘, v-v‘ ,, ~ _ . ‘ A-.. _ .‘ |.. ‘ .I..\. . "' #13, v. -. \b ~._..‘\ \ ‘ C O, - ‘ k '1 .x‘ 2’ ll ‘ _, .* ‘ Few?“ . ‘1 , u-._ «-.i ,. , ‘ b ‘ L 91- u , “ ‘ “I u _‘ l I- § ....\ V . C ‘Q- -“ ,1 (1:9 C .r . ‘~ ) 4 .r‘.‘ , ,g . . . .v_ !‘_ A "*i“'.’" o 4 I F I“. K "‘ d '3‘..-“ . r. A‘ F?” .‘ I’V- _ > "' " “ rut. ‘-'.".y ‘. 1."... .. - K 4 .{~\\ . - ;- ‘ " l“ M r. lzs‘ ‘ P. ‘ l ‘ . im‘ 5"} .‘Y \-'-14 . \ ~~A “ - ‘ ,‘, tion [27] enables simulation, concurrency analyses, test composition, and refinement checking via TOPO/ LOLA [66] and CADP [67]. 5. 1 Structural Analyses Structural analysis of object-oriented graphical diagrams refers to consistency check- ing at the diagram level. Consistency checks cover graphical and textual syntax inherent to the object—oriented graphical modeling notation used (e. g., OMT, UML), well-formedness assumptions and integration conventions inherent to the notation used or imposed by the formalization rules, and constraints relative to the intended target formal language. For ease of exposition, we group the discussion of structural analyses into three categories, which correspond to Steps A, B, and D of Figure 5.1, respectively. Sec- tion 5.1.1 describes to what extent the graphical editing environment can prevent certain types of graphical syntax violations from being drawn (Step A), or guide the user towards creating consistent diagrams. Section 5.1.2 presents many types of checks performed within individual class and state diagrams (Step B), while Sec- tion 5.1.3 enumerates several integration checks performed between the class diagram and each state diagram, and among all state diagrams (Step D). We use the term problem to denote an aspect of a diagram that warrants user attention. The severity of a problem and its potential consequences dictate whether it is classified as a wom- ing or as an error. Problems categorized as warnings do not have adverse effects on the behavior of the generated formal model (e.g., defining an attribute in a class in the class diagram but not using it in the corresponding state diagram). On the other hand, problems categorized as errors either indicate syntactically ill—formed diagrams (e.g., giving two states the same name in a state diagram) or have the potential to invalidate a generated formal model (e. 9., a state diagram expecting an event that is 61 never sent as a message from any state diagram in the model, an error that has the potential to cause deadlock). We use a conservative approach to classify problems; therefore, most problems described in the remainder of this section have been deemed errors. Errors must be corrected prior to formal model generation. 5.1.1 Preventing or Containing Diagram Errors The graphical editing environment can prevent certain types of graphical syntax vi- olations from being drawn, or guide the user towards creating consistent diagrams. We refer to these strategies as prevention and containment, respectively. Prevention. Consistency with a graphical syntax can, to a large extent, be im- posed by a graphical editing tool that has been enhanced by knowledge of the correct syntax, thus preventing many graphical syntactical errors from ever being drawn. Note that in an ordinary drawing application such as xfig [76], it is possible to draw a syntactically incorrect UML state diagram1 like the one shown in Figure 5.2. The state diagram shows a transition (directed are) from an initial pseudostate (small filled black circle) to a state (rounded rectangle labeled State_A), and a transition leaving StateJ. (directed are labeled with the event eventl). This state diagram is syntactically incorrect with respect to the graphical syntax of state diagrams because the transition labeled event] has a source state (StateJl) but no destination state. A generic drawing application like xfig has no knowledge of state diagram syntax, and therefore does not impose any relationships (or constraints on relationships) be- tween filled circles, rounded rectangles, and directed arcs. Further, although the state diagram example in Figure 5.2 uses only pseudostates, states, and transitions, noth- ing inherent in a generic drawing application like xfig would prevent the user from 1Our example pertains to the UML state diagram, but the general concept also applies to other diagrams, such as the UML class diagram, or other graphical notations, such as OMT. See Chapter ‘2 for an overview of OMT and UML syntax. 62 l l _ _ 4? f‘"l‘~‘T \ " milll\.a.:\-" - (1. . a A. V. ‘." "I 'J.a:.'1.€ l—AnA- ~«.. l V' ... A .. '-'v-‘. I l. ‘ 'x‘ ' ~ . . . " .c ..- ~Q ._ ‘ ’4‘. r‘ ." . ~- ' A ‘.,K. I. '- 12"» i “ v- s.‘. a ‘ A. _- ‘ a .-‘,_ N. “ ‘ -, ‘ l. f" d A,’ " Agn.‘ ~., V .v, H \0 “¢‘ \ A 1 “\A b (C drawing squares, triangles, and undirected lines, none of which is a valid component of a state diagram. . E 3.... A W Figure 5.2: Syntactically incorrect state diagram, with respect to graphical syntax However, a metamodelQ—based graphical editing tool, such as MINERVA [40, 47, 50, 51, 52] which supports both UML class and state diagrams, can prevent the construction of diagram components that are inconsistent with the metamodel for the corresponding type of diagram. For example, as shown in Figure 5.3, a transition in a state diagram must have a source and destination state and cannot be drawn otherwise with a graphical editing tool such as MINERVA that comprehends and enforces state diagram graphical syntax. Further, unlike a generic drawing application, MINERVA’S state diagram editor allows only those diagram components that are consistent with the state diagram metamodel, that is, pseudostates, states, and transitions, to be drawn. Preventing such well-formedness errors decreases the consistency-checking burden placed on other tools. . >/ State_A \ even” I State_B ] C J Figure 5.3: Syntactically correct state diagram, with respect to graphical syntax Containment. In addition to a graphical syntax, textual annotations are a com- mon feature of many graphical notations for object-oriented systems. OMT and 2Recall from Chapter 2 that a metamodel is a class diagram that describes the constructs of a modeling language and the relationships between the constructs. 63 . Y‘l ,- ..5 'r' ('3‘ A“ :4“ ‘ - o . ‘ ltv‘isvd ._ -' ‘ _rg.r_.LA.. to - -‘ . CV ‘ ¢V~V\ . ‘ . .4 \ iv a”; ...t.... v, "1" 1,. 0 O k" ."?‘Y“A ‘ ~; ~V-vr . o t, .\ ,. .z - .- 'L- \ .~ '0 . "r r .7 g -o .' 1 - \ ... \ shoa. . . . F‘ ‘4‘ " F v. '7 A 4.... ' ‘ A u ' ~ ‘Y '7' 1 l \r .\ '\ - .A'A- l ‘ I 9."? ’ 'v m t q o“ AA‘ .‘ ‘ , . _“ i - ‘ ~._.I‘i r. .‘ . ‘ A ..' r. _; . L."‘ " "I.‘ ’ ’ . A ‘. L. - . \ " .- . a- ‘VN V o ' A‘- I’ - Q ' s. . G . p ‘ « .4 -. A ‘ l r-z: ‘ - \. '. t“} V“ . " *. ‘-A q UML in particular use text in class diagrams to label classes, to list attributes and operation/signal signatures, and to label relationships. They also use text in state diagrams to label states, and to describe events, guards, and actions on transitions between states. Many kinds of textual annotations in UML have their own suggested syntax to a certain extent. For example, the suggested textual annotation syntax for a transition label in a state diagram is described in Expression (5.1), where the actionErpressz’on may comprise a sequence of actions, some of which may be message sends [18]. The transition syntax currently supported by MINERVA [40, 47, 50, 51, 52] and Hydra [31, 48], described in Expression (5.2), allows message sends to be dis- played either as actions (e. 9., send(target0bjectName . signalName)) or separately, preceded by a caret (e.g., AtargetObjectName . signalName). This transition syntax is used in the following examples. eventSignature [guardConditton] / actionE-zrpressz'on (5.1) eventSignature eventNome eventName(parom1, . . . , parami) guardCondition booleanEccpression (5.2) actionExpression actionList messageList actionList actionl; . . . ;actionj messageList Amessagef‘. . ."message;c In a graphical editing tool that enforces the graphical syntax of state diagrams but places no restrictions on the entry of textual annotations such as transition labels, it would be possible to draw the state diagram shown in Figure 5.4. This state diagram, while obeying graphical syntax, has a nonsensical string as its transition label. Between the metamodel for overall diagram syntax and the user interface for a diagram editing tool, it is possible to offer the user some structured guidance for 64 i' u z‘ . P ‘ a V‘ . 'P v S . L...“ I i}. . . l'.‘ . 7‘ ,,. FV"_‘,P'I~1 9 \A A:..;.. I 9-‘11':.{l . . M...“ ..s l . . ~. ‘ . f— " V\ 4- Ola. _‘ Pr - ‘ I‘Vr ‘a "—..o.. ‘. t "'P ‘ .. (v I: a -_ ~w.. '— . .. . ‘ K 4.:_l." K S ta te_ A W the quick brown fox >( S ta te_B ] J Figure 5.4: Nonsensical transition label entering textual annotations. In MINERVA, for example, we present the user with separate text entry areas for the event name, parameter list, guarding condition, list of actions, and list of messages in a state diagram transition label. MINERVA combines all the information with the proper delimiting characters into one label for display. Enforcing the general syntactical structure of transition labels may also assist a parser or other consistency checking utility in pinpointing errors, for example in the event name, guarding condition, etc.. Even with such guidance, constructing structured nonsense may still be possible (although not very likely since we assume users generally have a valid transition label in mind), as shown in Figure 5.5. To prevent the nonsense transition label in this example, additional guidance could be provided to the user in terms of pop-up menus for state transition label components populated with information gleaned from the class diagram. However, diagram integration rules would need to be coded into the diagram editing environment, making it needlessly complex to maintain and slow to execute. Additionally, any item desired to be displayed in a transition label would first have to be entered in the class diagram, forcing the user to switch back and forth between diagrams. Bookkeeping would also need to be performed to invalidate transition labels that use information subsequently deleted from the class diagram. Text entry for items such as class, attribute, operation / signal, and state names could not be restricted, so parsing and consistency checking would-not be eliminated. We have found that using structural guidance to alleviate most textual syntactical errors, parsing to detect any remaining syntactical errors, and consistency checking to detect 65 V « D—y..V Q ‘ a ,. A. .‘ n I' . 4.. as 3 3.3.2... 1 ‘ I . ‘r-“vvr 1 b" . r ,, Ltn~ ~.:na4¢~ . .__ TV .7 ‘ . .‘ ‘ ‘suh‘ 5) , ‘ .'. ‘. V A, 4 ._ ' 1.. r . c“‘ ‘ “.‘fl q. \ l I P‘X‘Q- ‘I \Y,’ . c.\ '4(.. ~ .‘ . v.‘ . ‘ I i h N l U” rlr‘ 1' v. ‘ ’ ‘ ‘ 9 -. “a a \T{‘ ‘J I‘ . .. A. ‘ ’4. I . _; ‘I'l‘ Y“ m. I~.L‘-. L . .. D... _ ‘ , h 5 4 ' - "“‘{A‘ All \\ A. AHA} \94,‘-: .I - 1‘ k 3‘} , ‘ "V "1" 0'~ ‘ . V‘ r“ v, ‘1 ‘ §. \ \. ~ \_‘j V," ‘ ‘ l “A ' I ~- . ,. ‘ 1“~ ”4“». -_ .1 (iv ‘ . . . “ ‘ k - definition/ usage and other discrepancies, including graphical syntax anomalies such as a missing start state, effectively distributes the responsibilities for consistency checking between the diagram editing environment and other utilities. [ State A \ mary[had]/a"little.lamb fState B 1 Figure 5.5: Structured nonsense on a transition 5.1.2 Problems Within a Diagram This section discusses problems within individual diagrams; that is, the class diagram and each state diagram. A diagram and its elements are checked for graphical and textual syntax problems and violations of well—formedness assumptions that could not be prevented by the graphical editing environment, such as a missing start state in a state diagram or an invalid class, operation/ signal, or attribute name in a class diagram. Diagram elements may also be checked for consistency with the target formal language in terms of reserved word usage. Figures 5.6 and 5.7 list class di- agram well-formedness assumptions (overall diagram assumptions and assump« tions about the various parts of the class diagram). Figure 5.8 lists state diagram well-formedness assumptions. 5.1.3 Problems Between Diagrams This section discusses problems between diagrams; that is, between the class diagram and each state diagram, and between state diagrams. The class diagram provides the context for other diagrams; therefore, an important type of consistency check between the class diagram and each state diagram is definition/ usage check. Such 66 o Naming — A valid name depends on the formalization rules and target language con- straints (such as no whitespace, no special characters, must start with a particular letter, etc.) — Name uniqueness among classes — Name uniqueness among attributes within a class — Name uniqueness among operations/ signals within a class — N o reserved words from target language used as names a Data Types - A valid data type depends on the formalization rules and target language constraints (for example, Promela does not support real numbers as a data type) 0 Inheritance — No circular inheritance (formal model generation cannot handle cycles) — No multiple inheritance Figure 5.6: Overall class diagram well-formedness assumptions 67 0 Classes — A class must have a name 0 Attributes — An attribute must have a name — An attribute must have a data type An attribute may have a default value — A default value must match the attribute’s data type c Operation/Signals — An operation/ signal must have a name — An operation/ signal may have parameters (depends on formalization rules and target language constraints) — An operation/ signal parameter must have a data type — An operation/ signal may have a return data type (depends on formaliza- tion rules and target language constraints; McUmber’s UML-to-Promela formalization uses only asynchronous signals) Figure 5.7: Class diagram parts well—formedness assumptions 68 nus... . . \ .V\ a 1. V. 4A mil o Naming —— Name uniqueness among all states — N o reserved words from target language used as names a Hierarchy - State diagrams are hierarchical and as such may have nested levels — The topmost level of a state diagram must have exactly one start state 0 States A simple state, composite state, concurrent-composite state, or concurrent region must have a name A simple state may have entry or exit actions A concurrent—composite state must contain more than one concurrent re- gion — A concurrent region must have exactly one start state 0 Transitions — A transition may have associated actions 0 Actions — An action may be an assignment statement or a message send Figure 5.8: Overall state diagram well-formedness assumptions 69 v». a check ensures, for example, that all the variables used in actions and messages on transitions or entry/ exit actions in states within a state diagram have been defined as attributes in the owning class in the class diagram, and that events used on transitions within the state diagram have been defined as operations/ signals in the owning class. Usage of variables or events in a state diagram without their having been defined in the class diagram will lead to syntax errors in the target language formal model; thus, such usage is flagged as an error. However, definition of attributes or operations/signals in a class without their use in the corresponding state diagram is a common practice during the evolution of a system’s model. Attributes and operations/ signals may be introduced in a class with the intent of being used at some point in the future when more detail is added to the model. Therefore, this type of inconsistency between a class and its corresponding state diagram is flagged as a warning only. Another check between state diagrams alerts the user when a state diagram expects a message that no object sends. This situation is an inconsistency among the state diagrams contained in the entire model that may cause a deadlock when the behavior of the model is explored with the target—language analysis tool. It is therefore considered an error . Integration assumptions between the class and state diagrams are listed in Fig- ure 5.9. Problems between the class diagram and a state diagram are listed in Fig- ure 5.10, while problems between state diagrams are summarized in Figure 5.11. Both Figures 5.10 and 5.11 include a brief problem description, a classification of the prob- lem as a warning or an error, and the potential consequence if the problem is not detected and addressed prior to specification generation. 70 0 \“v . . . _ 0 State diagram ownership — A class may have zero or one state diagrams associated with it; we say that the class owns the state diagram — A state diagram must be owned by a class 0 Attributes — Variables used on the left hand side of assignment statements in actions within states or on transitions in a state diagram must be defined as at- tributes in the owning class — Variables used in event and message parameter lists, guarding conditions, or expressions on the right hand side of assignment statements must be defined as attributes in the owning class 0 Operations / Signals - The events handled by a state diagram must be defined as opera- tions/ signals in the owning class 0 Messages — The recipient of a message must be defined as a class in the class diagram — Messages sent must be defined as operations / signals in the owning class of the recipient state diagram — The recipient class of a message must have a state diagram associated with it For each message sent to a recipient state diagram, there should be at least one transition in the recipient state diagram that handles the message. Figure 5.9: Integration assumptions between class and state diagrams 71 Problem Classification Consequence Use of a variable in a state diagram without it being de- fined as an attribute in the owning class in the class di- agram Error Target language syntax er- ror Defining an attribute in a class in the class diagram but not using it as a variable in the corresponding state diagram Warning No adverse effect on target language specification, ex— cept in the case of some model checkers may con- tribute to state space explo- sion Use of an event in a state di- agram without it being de- fined as an operation/ signal in the owning class in the class diagram Error Target language syntax er- ror Defining an operation / signal in a class in the class dia- gram but not using it as an event in the corresponding state diagram, or as a mes- sage in any state diagram Warning No adverse effect on target language specification Figure 5.I0: Problems between class and state diagrams 72 Problem \ lat? (If " l \_,"4 ." ‘ -. .\ _ ‘ \ :r = .. i d V 'V» \ ;.~‘ , “"“““clt 1 MY q . -. ' ‘N. ‘ . I .. ‘ ka." (’1‘ V léa" . . ‘ .5 \ , A F i . ‘.,.: .‘ E-Ii ,"3 '_‘l ' A E‘- I “’v. a ., ,_ ‘3 H . \O v g. . . \ I.- c I. Problem Classification Consequence Use of an operation/ signal in a message send to a state diagram that never handles that event Error Potential deadlock: If the message send takes place, then the recipient state dia- gram will be unable to han- dle the incoming event and will deadlock. Use of an operation/ signal in a message send to a state diagram when the opera- tion/signal is not defined in the owning class of the recip- ient state diagram Error Target language syntax er- ror Expecting an event that is never sent as a message from any state diagram Error Potential deadlock: If an ob- ject enters a state where the only transitions out of that state depend upon the re- ception of messages which will clearly never be sent, then the object will deadlock in that state. Figure 5.11 : Problems among state diagrams 73 I i ‘ ‘ ' v 1". v- . , .~ k." ..u‘ ”3'. \‘. 'Vi‘v'rh Cr. ‘ i ‘ V I ....‘~ I“? ‘. a A.\. I I ’ — . I !I-“ ' ‘ o... . .v _ . , l . . jug! \ 1 ‘ |‘r, _. . -‘.. '::\I .7 . . \n \ , ‘ .x....-‘...-\ b‘ .‘ . H r 1 ' c l [J ‘ ,. :_, - . '{va ,4; : ..«..;.‘..I‘..v- ' . (‘J M p—d rn K. \‘n ..v _ K.“‘ .“Al. (V ... , I le".--§ . ‘ l ' ._ ‘4 - . \‘_ a .. .\ vy‘_ 1 1 ‘~.-“ ‘1‘ \ :v 2M; 1. T' all ”Y ‘ u‘.. g, \ .p v. V .a“"[ ’ . '1 j.» ‘k -. . L _ a 4‘- ~.' .‘ V. ‘i LS. e-‘.{.v-, . ‘*." o 1" x, If ‘J ? _ \f‘ 1' a C‘AI --: ., 5.2 Behavioral Analyses After addressing any problems detected with structural analyses and then successfully generating the target language formal model for the model of the software system, behavioral analyses can be performed with the appropriate target language analysis tools. In the case of Promela models, we use Spin [69], a Promela model analysis tool that offers simulation and model checking capabilities. Simulation is useful for vali- dating behavior of specific paths of execution through a given system. The analysis is not complete in the sense that it is not possible to validate every possible scenario. Once simulation has been used to validate the “common” scenarios and critical “ex- ception cases”, then model checking can be used to help check that the entire model satisfies specific critical properties. These analyses, corresponding to Steps F, G, and H of the process depicted in Figure 5.1 (page 60) respectively, are described in the remainder of this chapter. 5.2. 1 Simulation Simulation (Step F) enables validation of behavioral requirements or scenarios, and debugging of a system model. Hydra can be used to automatically generate Promela models from UML diagrams in order to use Spin’s simulation utilities to “execute” the UML diagrams. Simulation reveals whether a system model executes at all, and if it does, how closely it conforms to expected behavior. Because the effort (construct- ing temporal claims) and resources (memory and time) required to perform model checking are more demanding than that needed for simulation, we find that using an iterative process of simulation and visualization of results within UML diagrams, refinement of UML diagrams, and automatic regeneration of a formal model enables us to gain a better intuitive understanding of a system and to correct many flaws prior to using model checking. 74 y I '1 .I‘ ‘tllli'; '.’l a bl ,‘I'grl VI; p ,4 .. .u_¢ “L... L ' l a (‘37-. I‘" V V .. (‘°“ ‘11. Y I '1 .‘Iv ‘c‘l-". t . . ‘ I LilAIII‘P‘ 5 .' '~4 L‘ D" -‘ 4‘ .1, , LA-L. (I‘m, : ‘ ‘ A.‘Al.“ \Nrg‘ . .‘ _t. (r - . “Git; t ‘ r‘.- '4 UH». ' ‘a‘ ‘.v‘ ‘. 5.2.2 Model Checking Model checking [69, 70] (Step G) can be used to check for violation of global properties. Each simulation run interleaves the execution steps of various concurrent components, but, nonetheless, follows only one particular execution path. Model checking, on the other hand, expands a restricted set of execution paths from all possible interleavings 3 By exhaustively exploring of execution steps into one large graph, or state space. this state space, model checking can automatically detect deadlocks, test system invariants against a model, and check temporal claims. Deadlock usually indicates a communication protocol error between objects in a system model. System invariants may, for example, check that the value of an instance variable does not fall outside a certain range. Temporal claims usually test properties such as “something good always happens,” or “something bad never happens.” If a claim is violated, then model checking produces a counterexample, which is a sequence of execution steps that demonstrates how the claim was violated. Counterexample traces, which can themselves be simulated (Step H), can be extremely useful in tracing the source of errors. In our approach, we use requirements-based properties and model checking to detect counterexamples in order to validate UML models. That is, we are looking for counterexamples (indicating flaws in a UML model) rather that trying to verify correctness of a model. In this dissertation, the phrase “verified successfully” means that Spin did not produce a counterexample in an exhaustive search of the generated state space, while “failed” means that the property did not hold, and Spin did produce a counterexample. 3Because of what is known as the state explosion problem, model checkers in practice must use some technique, or combination of techniques, to reduce the state space. Spin in particular uses the partial order reduction to limit the number of interleaving sequences considered [69, 70]. 75 Chapter 6 Visualizations This chapter discusses visualization techniques that we have developed for results of both structural analyses of diagrams and behavioral analyses of generated formal models. For illustration purposes, we focus primarily on visualization of results from the analyses enabled by McUmber’s UML-to-Promela formalization [31]; thus, the model development and analysis process described in Chapter 4 for use with the model development and analysis framework instantiated in Chapter 4 is reproduced in Figure 6.1 for convenience to the reader. The bold directed arcs 1—4 represent feedback of analysis results to diagrams, discussed in this chapter. We visualize results in terms of both original and newly generated, complementary, diagrams in order to guide the user in refining the original diagrams modeling a system. The following sections overview visualizations of results of both structural and be- havioral analyses, including generation of new UML diagrams from behavioral anal- ysis results. We introduce a small example for illustration purposes in Section 6.1. Feedback lines 1—4 in Figure 6.1 represent feedback of analysis results to diagrams. Feedback lines 1 and 2, discussed in Section 6.2, represent feedback of results from structural analyses of diagrams, while Feedback lines 3 and 4, discussed in Section 6.3, represent feedback of results from behavioral analyses of a generated Promela model 76 (A) (and generate trace data) I I “___‘ I I Draw/refine model: _, I I (1) Class diagram 3 (2) State diagram(s) <—‘ I I E, < I .2 Z l v I '° I 1 m I 2 g I (B) Pre-processing checks 95.43 I E E I Tu > B , g 2 l v I (C) . . —— S I I Output Intermediate ‘11 g Eb representation i 2'3 .23 l |__ 8‘ E 3 I g ”9 l I _ v 8 ’w‘ e I g l (D) Intermediate checks —-2— (g t— I E” e I E. ' '2 3‘ ' (E) E I § I Generate target language 0,3 I 8 formal model § .0 I -1 — V — o :n r R I _ B I (F) Simulate model E g 8 ’5 (and generate trace data) a > i g E I o _5 ‘3 E I (G) . H E Q! Model check properties 0 m l «I E | I a o I m b | (H) . l Simulate counterexample . 4 I Figure 6.1: Iterative and incremental model development and analysis process, reprised from Figure 4.4. Bold arcs 1-—4 represent feedback of analysis results to diagrams. 77 (specifically, from simulation or simulation of counterexamples with Spin). Because screen shots of the MINERVA GUI do not reproduce well, in this chapter we simulate what the user would see for each visualization example by providing either textual output or drawings of diagrams. “Highlighting in color” is simulated by drawing the affected portion(s) of the diagram(s) in bold. 6.1 Producer- Consumer Example To illustrate structural and behavioral visualizations in the following sections, we introduce a small Producer—Consumer model. While not specific to the embedded systems domain, the Producer- Consumer problem has the advantages of being both well-known and small enough to illustrate several visualizations effectively, and it enables us to demonstrate a key issue in embedded systems design, namely, the im- portance of coordinated inter-object communication. The class diagram for the model is shown in Figure 6.2. Each class has a state diagram associated with it that describes its behavior. Additionally, the system is represented by a special class, the _SYSTEMCLASS_, that is an aggregate of classes representing its main components, the Producer and Consumer classes. We model one Producer and one Consumer as indicated by the (default) multiplicity of one on the association between the .SYSTEMCLASS- and each of the Producer and Con- sumer classes. This variation of Producer-Consumer follows a very simple supply- and-demand philosophy: the Producer waits for the Consumer to demand an item before supplying one. We assume that the Consumer does not make another demand until the Producer has handled the previous demand. Additionally, the Producer sup- plies only a limited number of items (five, as indicated by the default value1 of the 1If a default value is not given, then Spin [69] automatically sets a variable’s initial value to zero; however, not all target languages behave this way. For example, in the absence of a default value, SMV [75] non-deterministically chooses a variable’s initial value from the variable’s range of possible values. 78 limited Illlm E deman b _ . at «‘4 04 II \‘ ‘47- ‘ ‘v-,. 'N t. ‘ . Q A ‘- ‘ attribute limited-ed). The Producer keeps track of how many items it has supplied in the attribute num.made. _SYSTEMCLASS_ 0K0: void Producer limited_ed: int = 5 num_made: int = O Consumer demand(): void Figure 6.2: UML class diagram for Produce'r- Consumer model The state diagrams for the Producer and Consumer are shown in Figures 6.3 and 6.4, respectively. Upon instantiation, the Producer sends an OK message to the _SYSTEMCLASS- and enters its Waiting_For_Demand state. Until it has supplied the entire limited run of items, the Producer responds to demands from the Consumer, increments its counter that tracks the number of items it has supplied, and enters its Advertise state. The transition from state Advertise to state Waiting_For_Demand has no explicit event or guard. Instead, it has an implicit event done that causes the Producer to return immediately to state Waiting_For_Demand. Once the Pro- ducer has supplied the entire limited run of items, it enters the Sorry-Sold_0ut state. The Consumer starts in its HaveMoneleilLSpend state. The transition from state Have_Money_Will_Spend to state Waiting-For_Supply has no explicit event or guard. 79 I . r w n‘ w ltftvil‘... H 1 «e '. Q« q .\ film A.) .‘ .4. , I H 4 I aa‘...¢ . ‘4‘; .I s A S ‘ RBI: Instead, it has an implicit event done that causes the Consumer to transition immedi- ately to state Waiting-For-Supply after sending a request to the Producer. Likewise the transition from state Waiting_For_Supply to state Have_Money_Will_Spend fires immediately. demand[num < limited_ed] /num := num + 1 " SYSTEMCLASS .OK \ “ J k“ — {WaitingJioLDemandl ll/ (Advertise fl [num_made >= limited_ed]/ @rry_Sold_OuD Figure 6.3: UML state diagram for Producer Have_Money_Will_Spend []/ []/"Producer.request Waiting_For_Supply Figure 6.4: UML state diagram for Consumer 80 '\ I \QPir'inr. l .JLt us a 'l r . ._ . I] ll'.lr.:4":;.‘ ..x‘.“‘ ‘ . -v-~.. I"’\b"' ‘ l‘ ....-: ~ «. ‘ V V". '~ ail—i {' an.” ‘. -. “a: ’4‘ l ..v \, 4. (i . ”I ~ J l q ' t.‘ ' v (1,... ‘. r *-.f' Q1: i'i‘dlf‘ . '4 V I“. . y - as, or .. l l. .‘4 V. ,. h '1 I, F. i ii"... -.‘(\). 6.2 Structural Visualizations Structural visualizations, as described in the next subsection, include visualization of problems within and between diagrams. Problems within an individual diagram are visualized within that diagram, while the different parts of a problem between diagrams are visualized within the affected diagrams. 6.2.1 Within and Between Diagrams Visualizations of structural analysis results include displaying text-based messages and using color to highlight the location of problems in UML diagrams within the graphical editing environment (e.g., MINERVA). Problems within individual diagrams are simply highlighted within each diagram, while problems between diagrams may be presented in a specific ordering. For example, definition / usage problems between class and state diagrams may show the class diagram first, while send/receive problems between state diagrams may show the sender first (if there is one) and then the receiver. 6.2.2 Structural Analyses Applied to the Producer- C'onsumer Example, with Visualizations First, the diagrams are drawn in MINERVA. The intermediate representation is then generated and given to Hydra for structural analysis, which reveals several prob- lems as shown in Figure 6.5. Each problem reported is prefixed with four asterisks “*Ikaluk”) and a classification of warning or error. For example, the errors on lines 3, 5, 7, 9, and 11 in Figure 6.5 indicate inconsistencies between the class diagram and the state diagram for the Producer. In each case, the problem stems from the fact that the variable num has been used in the Producer state diagram but has not been declared. The error corresponding to these messages is visualized by highlighting the 81 ‘ a "ll l ”III ‘11.": *1 Or . Producer I. '. I 1 . ’-",n~\'- ~0. ‘1‘."‘51[A11 Il. ‘ . . .> -, Pep" H 1‘. ' ‘. a tanta. O ‘ I P". ,V‘ f , ‘ ,. " u u s ‘1'. l_ . “I‘ 3 parse : 1 tu\‘ :: .. ‘ vu‘ I: . “.‘ :- ’3‘. 4 ‘.’- ” ".t I... i! ‘..‘ , . (“I ..“ K LIP! . . ‘_~ "‘.; ‘. .‘ I . ‘ \L“ s I” {'1 L1' f‘ appropriate transition(s) in the Producer state diagram, and then highlighting the Producer class in the class diagram, as simulated in Figures 6.6 and 6.7, respectively, to indicate that a variable has been used, but has not been declared. The actual error (determined by the user after evaluating the aforementioned error messages together with the corresponding visualization) is that the variable num has been used instead of the declared variable num_made. To correct the error, we revise the appropriate transition(s) in the Producer state diagram to use the declared variable num_made. The revised Producer state diagram is shown in Figure 6.8. 1 **** Starting...Hydra V1.4 (4/18/2002) 2 parse complete 3 **** ERROR Class: [Producer] State: [Waiting_For_Demand] 4 Variable num is undeclared 5 **** ERROR Class: [Producer] State: [Waiting,For_Demand] 6 Variable num is undeclared 7 **** Error: variable num undefined in transition 8 demand[num < limited_ed]/nun := num + 1 9 **** ERROR Class: [Producer] State: [Waiting_For_Demand] 10 Variable num is undeclared 11 **** Error: variable num undefined in transition 12 demand[num < limited,ed]/num := num + 1 13 **** Warning Class: [Producer] 14 Instance variable ’limited_ed’ is declared but unused 15 **** Warning Class: [Producer] 16 Instance variable ’num_made’ is declared but unused 17 **** Warning Class: [Consumer] No Initial state 18 **** ERROR Class: [Consumer] State: [Have_Money_Will_Spend] 19 Signal ’request’, sent to class Producer, is not declared 2o **** Warning Class: [_SYSTEMCLASS-] State: [Done] 21 State can never be exited (no outbound transitions) 22 **** Warning Class: [Producer] State: [Sorry_Sold_Out] 23 State can never be exited (no outbound transitions) Figure 6.5: Structural problems reported by Hydra Line 18 in Figure 6.5 reports that the signal request is not declared for class Producer in the class diagram, although it is used in the Consumer state diagram to send a message to Producer. This error represents another inconsistency between 82 demand[num < limited_ed] /num := num + 1 " SYSTEMCLASS .OK ‘ T ) o " — {Waiting_For_Demandl ll/ Advertise [num_made >= limited_ed]/ (Sorry_Sold_OuD Figure 6.6: UML state diagram for Producer showing highlighted transition from state Waiting_For_Demand to state Advertise that uses the undeclared attribute num _SYSTEMCLASS_ 0K0: void . Producer 1 * limited_ed: int = 5 Consumer num_made: int = O demand(): void Figure 6.7: UML class diagram for Producer-Consumer model showing highlighted class Producer that has not declared the attribute num nor the signal request 83 demand[num_made < limited_ed] /num_made :2 num_made + l " SYSTEMCLASS .OK \ ) G 7 _ @aitingjioLDemand) [l/ (Advertise [num_made >= limited_ed]/ [Sorry_Sold_OuD Figure 6.8: UML state diagram for Producer after fixing structural problems. (Used declared attribute num_made instead of undeclared num on transition from state Waiting_For_Demand to state Advertise.) diagrams and is visualized by first displaying the highlighted transition in question in the Consumer state diagram as simulated in Figure 6.9 and then the highlighted Producer class in the class diagram as (previously) simulated in Figure 6.7. The actual error is that the signal request has been used instead of the declared signal demand. To correct the error, we revise the message on the transition in question in the Consumer state diagram to use the declared signal demand. (Alternately, we could have revised the declarations in the Producer class in the class diagram to declare the signal request.) Line 17 in Figure 6.5 (page 82) describes a well-formedness warning specific to the Consumer state diagram. Because the problem is a missing start state, only the state diagram for the Consumer itself can be shown, along with a textual mes- sage indicating the problem. The developer must decide which is the initial state (Have_Money_Will_Spend or Waiting_For-Supp1y) and connect a start pseudostate to it in order for any of the Promela code representing the Consumer state diagram in the generated formal model to be reachable. To correct this error, we add a start state and an initial transition to state Have-Money_Will_Spend, indicating that state Have_Money_Will_Spend is the initial state of the Consumer state diagram. The re- 84 Have_Money_Will_Spend Il/ []/"Producer.request Waiting_For_Supply Figure 6.9: UML state diagram for Consumer showing highlighted transition from state Have-Money-Will_Spend to state Wait ing_For_Supply that uses the undeclared signal request vised Consumer state diagram, handling the errors on both Line 17 and Line 18 in Figure 6.5 (page 82), is shown in Figure 6.10. For completeness, Figure 6.11 shows the class diagram after structural revisions (no changes were needed). We apply structural analyses to the intermediate represen- tation generated from the revised diagrams and find no errors. Now that structural problems have been addressed, Promela models can be generated from the diagrams and behavioral analyses applied. The next section discusses the types of visualiza- tions possible from Spin’s behavioral analysis results and then demonstrates them in terms of the Producer- Consumer example. 85 “_SYSTEMCLASS_.OK Have_Money_Will_Spend []/ []/"Producer.demand Waiting_For_Supply Figure 6.10: UML state diagram for Consumer after fixing structural problems. (Used declared signal demand instead of undeclared request on transition from state Have_Money_Will_Spend to state Waiting-For-Supply. Added initial transition to state Have_Money-Will_Spend.) 86 _SYSTEMCLASS_ OK(): void Producer Consumer limited_ed: int = 5 num_made: int = 0 demand(): void Figure 6.11: UML class diagram for Producer- Consumer model after fixing structural problems. (N 0 changes were made.) 87 6.3 Behavioral Visualizations Behavioral visualizations, as described in the following subsections, include state dia- gram animation, sequence diagram generation, and both collaboration diagram gen- eration and animation. Refinements shown to the Producer- Consumer diagrams in this section will be described step-by-step in Section 6.3.4. To enable feedback to existing state diagrams, MINERVA offers the user three ways to augment the interme- diate textual representation that will later be translated into Promela. These choices are: “States Only”, “Transitions Only”, and “States and Transitions” (the default generation of the intermediate textual representation uses none of these options). The choice selected affects the type of print statements2 added to the intermediate representation, and thus the final formal model. These print statements, combined with several options for Spin runtime flags, affect the level of detail present in the trace output from Spin and thus the type of visualizations that can be achieved. The default generation does not add any extra statements to the intermediate represen- tation. Currently the formalization to Promela does not incorporate identity tags for graphical elements, so with no extra statements, no automatic feedback to the original diagrams can be generated other than possibly highlighting states based on a unique naming scheme (depending on the Spin flags chosen, it may still be feasible to generate sequence and/or collaboration diagrams). MINERVA’S user interface offers the choices “States Only” and “Transitions Only” as mechanisms to add special print entry actions to states or special print actions to transitions, respectively, while the choice “States and Transitions” does both. These special print actions, while not explicitly available to the user at the UML diagram level, are added transparently to the intermediate representation that is then given to Hydra. The generated Promela mOdel will have appropriate print statements that will fire when states are entered or 2Note that this technique will only work for target languages with a print statement. Future work includes investigating a more general approach to instrumentation that adds boolean variables to the formal model to indicate when a state has been entered or when a transition has been taken. 88 transitions are taken during the exploration of the model. Trace data captured from both random simulation and simulation of counterex- amples obtained from model checking results enables animation of state diagram(s) originally drawn by the user (via the print statements just discussed), and generation of new sequence and collaboration diagrams. An example of raw trace data output from a Spin simulation with no runtime flags of a Promela model generated from an intermediate representation3 augmented with print statements using the “States and Transitions” option is shown in Figure 6.12. The data has been manually elided and formatted for space considerations and readability as follows: (1) As line 1 indicates, data from the beginning of the trace has been elided so that the figure shows only the last five transitions and state entries (lines 2—31), plus the contents of all model queues at the end of the trace (lines 3441) ; and (2) Normally, the information from a print statement pertaining to a transition firing (such as shown in lines 2—4) or a state being entered (such as shown in lines 6—7) would appear all on a single line, with data fields delimited by the character ‘@’. This data can be processed into either a human- oriented report, as shown in Figure 6.13, or visualization instructions for MINERVA as shown in Figure 6.14. The numbers delimited by ‘@’ characters in the long strings in Figure 6.12 are the graphical element identity numbers from MINERVA’s internal representation. 6.3.1 State Diagram Animation A state diagram, originally drawn by the user, depicts the behavior of a class. De- pending on the amount of detail present in the trace data (which, in turn, depends on the instrumentation option chosen at the time of generating the intermediate 3The intermediate representation used to generate the formal model that produced the trace data in Figures 6.12, 6.13, and 6.14 was created from a refined version of the diagrams in Figures 6.8 (page 84), 6.10 (page 86), and 6.11 (page 87). Figures 6.12, 6.13, and 6.14 are for illustration purposes only; however, the refinements to the diagrams presented in the next few sections will be described step-by-step in Section 6.3.4. 89 ochsmauio— [manually elided, formatted for readability] TRANSITIONQQOQ130817257517@ProducerQ209130692280326 @Waiting_For_Demand@209130753228840 @Advertise0209130817257519@demand in state Producer.Advertise STATEQProducerQQOQ130692280326 @Advertise@209130817257519 TRANSITIONQ2091343017410580Producerfl209130692280326 @Advertise@209130817257519 @Waiting_For-Demand@209130753228840® in state Producer.Waiting_For_Demand STATEQProducerQ209130692280326 @Waiting_For_Demand@209130753228840 TRANSITIONQ2091307480514900Consumer®209130692280330 @Waiting_For_Supply@209130747068447 @Have_Money_Will_Spend@209130736058394©supply(edition_num) in state Consumer.Have_Money_Will_Spend STATEQConsumerc209130692280330 @Have_Money_Wi11_Spend@209130736058394 TRANSITION0209130748051488@Consumer@209130692280330 @Have_Money_Wil1_Spend@209130736058394 @Waiting_For_Supp1y@2091307470684470 in state Consumer.Waiting_For_Supply STATEQConsumerQQOQ130692280330 @Waiting_For_Supply@209130747068447 TRANSITIONQ209130817257514©Producer®209130692280326 @Waiting_For_Demand@209130753228840 @Sorry_Sold_Out@2091308172575160 in state Producer.Sorry_Sold_Out STATEQProducerQ209130692280326 @Sorry_Sold_Out@209130817257516 timeout #processes: 3 416: 416: 416: queue 2 (_SYSTEMCLASS_-q): Producer_V.limited_ed = 5 Producer-V.num_made = 5 queue 3 (Producer_q): [demand] Consumer_V.edition_num = 5 queue 4 (Consumer_q): queue 5 (Consumer_supply_p1): queue 1 (t): [free] proc 2 (Consumer) line 158 "producer_consumer_.pr" (state 37) proc 1 (Producer) line 110 "producer_consumer_.pr" (state 47) proc O (_SYSTEMCLASS_) line 64 "producer_consumer_.pr" (state 48) 3 processes created Figure 6.12: Raw trace data output from Spin with no flags 90 IOWNO>UIBGJM~ Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object "-SYSTEMCLASS_" transitions from state "Initial" to state "Create_Producer" on event "modelstart" "_SYSTEMCLASS_" enters state "Create_Producer" "Producer" transitions from state "Initial" to state "Waiting_For_Demand" on event "modelstart" "_SYSTEMCLASS_" transitions from state "Create_Producer" to state "Create_Consumer" on event "OK" "Producer" enters state ”Waiting_For_Demand" "_SYSTEMCLASS_" enters state "Create_Consumer" "Consumer" transitions from state "Initial" to state "Have_Money_Will_Spend" on event "modelstart" "_SYSTEMCLASS_" transitions from state "Create_Consumer" to state "Done" on event "OK" "_SYSTEMCLASS_" enters state "Done" "Consumer" enters state "Have_Money_Will_Spend" "Consumer" transitions from state "Have_Money_Will_Spend" to state "Waiting_For_Supply" on event "" "Consumer" enters state "Waiting_For_Supp1y" "Producer" transitions from state "Waiting_For_Demand" to state "Advertise" on event "demand" "Producer" enters state "Advertise" "Producer" transitions from state "Advertise" to state "Waiting_For_Demand" on event "" "Producer" enters state "Waiting_For_Demand" "Consumer" transitions from state "Waiting_For_Supply" to state "Have_Money_Will_Spend" on event “supply(edition_num)" "Consumer" enters state "Have_Money_Will_Spend" "Consumer" transitions from state "Have_Money_Will_Spend" to state "Waiting-For_Supply" on event "" "Consumer" enters state "Waiting_For_Supply" "Producer" transitions from state "Waiting_For_Demand" to state "Advertise" on event "demand" "Producer" enters state "Advertise" "Producer" transitions from state "Advertise" to state "Waiting-For_Demand" on event "" "Producer" enters state "Waiting_For_Demand" "Consumer" transitions from state "Waiting_For_Supply" to state "Have_Money_Will_Spend" on event "supply(edition_num)" "Consumer" enters state "Have_Money-Will_Spend" [three more cycles, manually elided] "Consumer" transitions from state "Have_Money_Will_Spend" to state "Waiting_For_Supp1y" on event "" "Consumer" enters state "Waiting-For_Supp1y" "Producer" transitions from state "Waiting_For_Demand" to state "Sorry_Sold_Out" on event "" "Producer" enters state "Sorry_Sold_Out" Figure 6.13: Trace data from Spin processed into human-oriented report 91 1 (list 2 . . [12 previous instructions, manually elided] 3 (list "TRANSITION" "209130817257517" "Producer" "209130692280326" 4 "Waiting_For_Demand" "209130753228840" 5 "Advertise" "209130817257519" "demand") 6 (list “STATE" "Producer" "209130692280326" 7 "Advertise" "209130817257519") 8 (list "TRANSITION" "209134301741058" "Producer" "209130692280326" 9 "Advertise" "209130817257519" 10 "Waiting_For_Demand" "209130753228840" "") 11 (list "STATE" "Producer" "209130692280326" 12 "Waiting_For_Demand" "209130753228840") 13 . [38 more instructions, manually elided] 14 ) Figure 6.14: Trace data from Spin processed into visualization instructions for MIN- ERVA corresponding to lines 19—24 of Figure 6.13 representation), the items highlighted in the state diagram may be states entered, transitions taken, or both. We find that highlighting the transitions taken is espe- cially useful when there is more than one transition from the source state to the destination state (e.g., several transitions using the same event but different guard— ing conditions). Figures 6.15—6.18 simulate the state diagram animation steps that correspond to lines 19—24 in Figure 6.13. Bold arcs in Figures 6.15 and 6.17 indicate the transition taken in each step, while bold rounded rectangles in Figures 6.16 and 6.18 indicate the state entered in each step. 6.3.2 Sequence Diagram Generation Sequence diagrams complement state diagrams, portraying a single possible path through a collection of state diagrams. They are the isomorphic equivalent of collab- oration diagrams, depicting a single sequence of message sends and receives (directed lines) over time (a vertical column per object, with time increasing from top to bot- tom). Message ordering and potential race conditions can be visualized with sequence 92 demand[num_made < limited_ed] /num_made := num_made + 1 A SYSTEMCLASS .OK \ 7 ) . _ _ {Waiting_F0r_Demandl U/ACOnSumeI-_supp]y(num_made) Advertise [num_made >= limited_ed]/ (Sorry_Sold_OuD Figure 6.15: Highlighted transition corresponding to lines 19—20 of Figure 6.13. Pro- ducer transitions from state Waiting_For_Demand to state Advertise on event de- mand. demand[num_made < limited_ed] /num_made := num_made + 1 A SYSTEMCLASS .OK i ) 0—“ " ‘vQVaitingFoLDemandl []/"Consumer.supply(num_made) (Advertise j‘ [num_made >= limited_ed]/ (Sorry_Sold_Out I Figure 6.16: Highlighted state corresponding to line 21 of Figure 6.13. Producer enters state Advertise. 93 demand[num_made < limited_ed] /num_made := num_made + 1 " SYSTEMCLASS .OK T %‘ — #GVaitingjioLDemand! []/"Consumer.supply(num_made)( Advertise [num_made >= limited_edl/ [Sorry_Sold_OuD Figure 6.17: Highlighted transition corresponding to lines 22—23 of Figure 6.13 Pro- ducer transitions from state Advertise to state Wait ing-For.Demand on the implicit event done. demand[num_made < limited_ed] /num_made := num_made + l A SYSTEMCLASS .OK i ” j % " ' @aitingjioLDemand) []/"Consumer.supply(num_made) (Advertise [num_made >= limited_ed]/ (Sorry_Sold_OLD Figure 6.18: Highlighted state corresponding to line 24 of Figure 6.13 Producer enters state Waiting-For_Demand. 94 diagrams. Figure 6.19 shows the lifelines for three objects, _SYSTEMCLASS-, Pro- ducer, and Consumer, with messages depicted as arrows from the sender to the receiver labeled with the name of the message and the value of any parameters. This sequence of messages also corresponds to the series of events depicted in Figure 6.13 (page 91), although the trace data that generated this sequence diagram was produced by ex- ecuting Spin with more verbose output options4 than that used to generated the output in Figure 6.12 (page 90). For illustration purposes, a portion of the visual- ization commands generated by processing the verbose raw trace data is shown in Figure 6.20. 6.3.3 Collaboration Diagram Generation and Animation A collaboration diagram5 depicts a snapshot in time, a particular instance of com- munication between objects in the system (rectangles) via links (directed lines).6 Animation of a collaboration diagram, then, depicts a series of these snapshots over time. When playing back trace data in a collaboration diagram, MINERVA highlights message pathways (links) as they are used. While state diagrams describe the order in which objects communicate via events, the actual communication pathway between the objects is not visualized. In collaboration diagrams, messages are preceded by sequence numbers denoting the order in which messages occur. Optional information displayed about a class instance at each step in an animation may include attribute values, the object’s state, and for our visualization purposes, queue contents.7 F ig- ure 6.21 simulates a snapshot corresponding to the visualization instruction on line 4The command spin -C -g -1 -p -r -s -w specname.pr includes information about channels used, global and local variables, message sends and receives, and forces print statements and a high level of verbosity in the output from Spin. 5Recall from Chapter 2 that collaboration and sequence diagrams are isomorphic. 6This notation convention is specific to our editor MINERVA. UML syntax suggests using labeled arrows to indicate the direction of message flow across a undirected link in a collaboration diagram, whereas we have attached the message label to a directed link to represent our asynchronous event flow. 7Recall (Chapter 2) that McUmber’s formalization [31] uses queueing semantics. 95 SYSTEMCLASS : Producer : Consumer f L OK I i L OK I l i demand l I —___| I '1 supply 1 \i l | /I I ' demand ', i I supply 2 \E E l demand 5 E : supply 3 \l l : demand l l ————'1 I : supply 4 \: l l demand l l —'fi I I supply 5 \l l l /} i 1' E demand , l I Figure 6.19: Example sequence diagram corresponding to events depicted in Fig- ure 6.13 (page 91) 96 CDQKIO’U‘fiO-JM—a r-au-no—o NH0 13 Figure 6.20: Visualization commands processed from raw trace data output from Spin (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list (list "STARTOBJECTS") "OBJECT" "_SYSTEMCLASS_" "O" "2") "OBJECT" "Producer" "1" "3") "OBJECT" "Consumer" "2" "4") "ENDDBJECTS") "STARTTHREADS") "ENDTHREADS") "STARTQUEUES") "QUEUEDEF" "_SYSTEMCLASS_" "2" "0") "QUEUEDEF" "Producer" "3" "1") "QUBUEDEF" "Consumer" "4" "2") "ENDQUEUES") "STARTDATA") "CHAN" "evq") ll CHAN II II evt H) "CHAN" "wait") "CHAN" "_SYSTEMCLASS-_q") "CHAN" "Producer_q") "CHAN" "Consumer_q") "CHAN" "Consumer_supply_p1") "CHAN" Ht") [approximately 29 commands manually elided] "STATE" "Consumer" "209130692280330" "Have_Money_Will_Spend" "209130736058394") "STATE" "Producer" "209130692280326" "Sorry_Sold_Out" "209130817257516") "SEND" "2" "Consumer" "demand" "3" "Producer_q") HQUEUEII "3" "producer-q" "1" lldemandll) "STATE" "Consumer" "209130692280330" "Waiting_For_Supp1y" "209130747068447") "ENDDATA") with verbose flags 97 28 in Figure 6.20. As shown by the arrow on the link from Consumer to Producer, the Consumer is in the act of sending the message demand to the Producer, although the message has not yet reached the Producer’s queue. The sequence number “13” indicates that this message is the thirteenth message in the sequence being animated. :_S YSTEMCLASS_ queue = {} state = "Done" :Producer limited_ed = 5 l3: demand edition num = 5 num_made = 5 _queue :- {} queue = {} _ .. . .. state 2 .. Sorry__S 01 d_Out" state — Have_Money_Will_Spend :Consumer Figure 6.21: Example collaboration diagram corresponding to line 28 in Figure 6.20 6.3.4 Behavioral Analyses Applied to the Producer- C’onsumer Example, with Visualizations We now return to our Producer— Consumer example, modeled by the diagrams from Figures 6.8, 6.10, and 6.11 after fixing structural problems but prior to final refine- ments. The diagrams are reproduced here in Figures 6.22, 6.23, and 6.24 respectively, for reference. We generate the intermediate representation with the “States and Transitions” instrumentation option, translate it into a Promela model, and then run a simulation with Spin using verbose flags to determine whether the model behaves as we intended. The human-oriented report and sequence diagram generated from Spin’s processed 98 demand[num_made < limited_ed] /num_made := num_made + l " SYSTEMCLASS .OK \ j r " _ #GVaitingjzoLDemandl n/ (Advertise ”— [num_made >= limited_ed]/ Gorry_Sold_O© Figure 6.22: UML state diagram for Producer after fixing structural problems, re- peated from Figure 6.8. (Used declared attribute num_made instead of undeclared mum on transition from state Wait ing_For_Demand to state Advertise.) “_SYSTEMCLASS_.OK Have_Money_Will_Spend []/ []/"Producer.demand Waiting_For_Supply Figure 6.23: UML state diagram for Consumer after fixing structural problems, re- peated from Figure 6.10. (Used declared signal demand instead of undeclared re- quest on transition from state Have-Money-Will_Spend to state Wait ing_For_Supply. Added initial transition to state Have_Money_Will-Spend.) 99 _SYSTEMCLASS_ OK(): void Producer Consumer limited_ed: int = 5 num_made: int = O demand(): void Figure 6.24: UML class diagram for Producer— Consumer example after fixing struc- tural problems, repeated from Figure 6.11. (No changes were needed.) output are shown in Figures 6.25 and 6.26, respectively. We can also generate visu- alization instructions for state diagram animation, not shown, from Spin’s processed output, illustrating that the Consumer is able to send a second demand message before a first one has been handled by the Producer. The original intent was to have the Producer manufacture items on demand from the Consumer, but it is now apparent that in our naive model, based on the erroneous assumption that the Producer and the Consumer would take turns, the demands from the Consumer can out pace the Producer’s ability to fulfill them. The simulation eventually terminates due to three factors: first, the Producer reaches its Sorry-Sold-0ut state after making five items and thus is unable to fulfill any more demands; second, Promela queues must be of finite length;8 and third, the default simulation behavior for Spin is to block when attempting to enqueue a message on an already-full queue rather than losing the mes- sage. By the end of the simulation, the Producer is in a state where it cannot respond 8T he default queue length imposed by McUmber’s Promela formalization [31] is five. 100 to any more demands, the Producer’s queue is full of unmet demand messages, and the Consumer must block. Spin’s underlying execution model uses interleaving; that is, only one Promela process at a time may execute a step. Because Promela processes are not executed in lockstep (i.e., not executed simultaneously), Spin has extremely weak fairness heuris- tics (z'.e., processes can starve), and our simple model has no special measures to ensure that the Producer and Consumer behave in a coordinated fashion, the Con- sumer is able to send multiple demand messages to the Producer without waiting for them to be handled. In order to resolve this problem, we introduce handshaking; that is, each demand message from the Consumer is acknowledged with a new supply message from the Producer. (Handshaking is a commonly used technique in the em- bedded systems domain to ensure coordinated inter-object communication [39].) The revised class diagram and Producer and Consumer state diagrams are shown in Fig- ures 6.27 (page 104), 6.28 (page 104), and 6.29 (page 105), respectively. In the class diagram, class Consumer has been refined to include the new supply message, plus a new attribute called editionmum. The Producer state diagram has been refined to respond to a demand from the Consumer with a supply message that also carries the num_made value as a parameter to indicate which item in the limited edition series is being supplied. As shown in the Consumer state diagram, that value is stored in Consumer’s edition_num variable upon receiving a supply message from the Producer. After the diagrams are refined, we generate the intermediate representation again with the “States and Transitions” instrumentation option, translate it into a Promela model, and then run another simulation with Spin using verbose flags. Results are shown as a human-oriented report and a sequence diagram in Figures 6.30 (page 107) and 6.31 (page 108), respectively. These figures were also used earlier for illustration purposes in Figures 6.13 (page 91) and 6.19 (page 96). The refined version of the model seems to behave more in keeping with the original intent. The sequence dia- 101 wmammauuu Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object [elided 6 interleaved statements involving -SYSTEMCLASS_] "Producer" transitions from state "Initial" to state "Waiting_For_Demand" on event "modelstart" "Producer" enters state "Waiting_For_Demand" "Consumer" transitions from state "Initial" to state "Have_Money_Will_Spend" on event "modelstart" "Consumer" enters state "Have_Money_Will_Spend" "Consumer" transitions from state "Have_Money-Will_Spend" "Waiting_For_Supply" on event "" "Consumer" enters state "Waiting_For_Supply" "Consumer" transitions from state "Waiting_For_Supply" to "Have_Money_Will_Spend" on event "" "Consumer" enters state "Have_Money_Will_Spend" "Consumer" transitions from state "Have_Money_Will_Spend" "Waiting_For_Supply" on event "" "Consumer" enters state "Waiting_For_Supply" "Producer" transitions from state "Waiting_For_Demand" to "Advertise" on event "demand" "Producer" enters state "Advertise" "Consumer" transitions from state "Waiting_For_Supply" to "Have_Money_Will_Spend" on event "" "Consumer" enters state "Have_Money_Will_Spend" "Producer" transitions from state "Advertise" to state "Waiting_For_Demand" on event "" "Producer" enters state "Waiting_For_Demand" "Consumer" transitions from state ”Have_Money_Will_Spend" "Waiting_For_Supply" on event "" "Consumer" enters state "Waiting_For_Supply" "Consumer" transitions from state "Waiting_For_Supp1y" to "Have_Money_Will_Spend" on event "" "Consumer" enters state "Have_Money_Will_Spend" "Consumer" transitions from state "Have_Money_Will_Spend" "Waiting_For_Supply" on event "" "Consumer" enters state "Waiting_For_Supply" "Producer" transitions from state "Waiting_For_Demand" to "Advertise" on event "demand" "Producer" enters state "Advertise" [elided 23 more steps] to state state to state state state to state state to state state Figure 6.25: Human-oriented report for Pr‘oducer- Consumer example generated from the output of a Spin simulation with verbose flags 102 SYSTEMCLASS : Producer : Consumer :/ OK : OK l l l I l I I I l l E demand l {<___demand___,: : E demand I, | , E demand I, I a demand I |. E demand , ______.____.______._____..-_-______7\__7 Figure 6.26: Sequence diagram for Producer- Consumer example generated from the output of a Spin simulation with verbose flags 103 _SYSTEMCLASS_ OK(): void Producer Consumer limited_ed: int = 5 num_made: int = O edition_num: int = 0 supply(int): void demand(): void Figure 6.27: UML class diagram for Producer- Consumer example after fixing behav- ioral problems. (Added attribute edition_num and signal supply to class Consumer.) demand[num_made < limited_ed] /num_made := num_made + l A SYSTEMCLASS .OK i ‘ — _ @ting_For_Demandl []/"Consumer.supply(num_made) (Advertise l [num_made >= limited_ed]/ I Sorry_Sold_OuD Figure 6.28: UML state diagram for Producer after fixing behavioral problems. (Added message supply sent to Consumer on transition from state Advertise to state Wait ing_For_Demand.) 104 “_SYSTEMCLASS_.OK Have_Money_Will_Spend supply(edition_num)[]/ []/"Producer.demand Waiting_For_Supply Figure 6.29: UML state diagram for Consumer after fixing behavioral prob- lems. (Added event supply on transition from state Waiting_For..Supply to state HaveJ‘loneyJJilLSpend.) 105 gram in Figure 6.31 shows that each demand message from the Consumer, save the last, is met with a supply message from the Producer. Lines 41—46 of the human- oriented report in Figure 6.30 show that the simulation ends with the Consumer in its Waiting-For-Supply state and the Producer in its Sorry_Sold_Out state. The simulation trace data can also be processed to create visualization instructions for state diagram animation, not shown, that would end with steps highlighting the Con- sumer’s Waiting-For_Supply state and the Producer’s Sorry-Sold-Out state. From the state diagrams in Figures 6.28 and 6.29, we know that the Producer will never respond to the final demand shown in the sequence diagram of Figure 6.31. The Consumer deadlocks in its Waiting-For_Supply state. One approach to address the issue of the unmet demand is to alter the model as follows. Before accepting any demands from the Consumer, the Producer informs the Consumer of the number of items in the current collection as defined by limited_ed. The Consumer would thus have to add a new message with a parameter and an at- tribute in which to store the parameter’s value. The Consumer then compares the latest edition it has received (edition_num) with the total number of items in the collection to determine when it has acquired the entire collection and can thus stop sending demand messages. To explore the ramifications of this possible solution, we would refine the diagrams, generate a Promela model from the intermediate represen- tation once it has passed structural checks, and perform simulation or model checking with Spin. However, this example has served its purpose of illustrating types of struc- tural and behavioral visualizations, and so we do not refine it further. 106 ‘OWKIO’O‘fiQNH 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 4O 41 42 43 44 45 46 Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object Object "_SYSTEMCLASS_" transitions from state "Initial" to state "Create_Producer" on event "modelstart" "_SYSTEMCLASS_" enters state "Create_Producer" "Producer" transitions from state "Initial" to state "Waiting_For_Demand" on event "modelstart" "_SYSTEMCLASS_" transitions from state "Create_Producer" to state "Create_Consumer" on event "OK" "Producer" enters state "Waiting_For_Demand" "_SYSTEMCLASS_" enters state "Create_Consumer" "Consumer" transitions from state "Initial" to state "Have_Money_Will_Spend" on event "modelstart" "_SYSTEMCLASS_" transitions from state "Create_Consumer" to state "Done" on event "OK" "_SYSTEMCLASS_" enters state "Done" "Consumer" enters state "Have_Money_Will_Spend" "Consumer" transitions from state "Have_Money_Will_Spend" to state "Waiting_For_Supp1y" on event "" "Consumer" enters state "Waiting_For_Supply" "Producer" transitions from state "Waiting_For_Demand" to state "Advertise" on event "demand" "Producer" enters state "Advertise" "Producer" transitions from state "Advertise" to state "Waiting_For_Demand" on event "" "Producer" enters state "Waiting-For_Demand" "Consumer" transitions from state "Waiting_For_Supp1y" to state "Have_Money_Will_Spend" on event "supply(edition_num)" "Consumer" enters state "Have_Money_Will_Spend" "Consumer" transitions from state "Have_Money_Will_Spend" to state "Waiting_For_Supply" on event "" "Consumer" enters state "Waiting_For-Supply" "Producer" transitions from state "Waiting_For_Demand" to state "Advertise" on event "demand" "Producer" enters state "Advertise" "Producer" transitions from state "Advertise" to state "Waiting_For_Demand" on event "" "Producer" enters state "Waiting_For_Demand" "Consumer" transitions from state "Waiting_For_Supply" to state "Have_Money_Will_Spend" on event "supply(edition_num)" "Consumer" enters state "Have_Money_Will_Spend" [three more cycles, manually elided] "Consumer" transitions from state "Have_Money_Will_Spend" to state "Waiting_For_Supply" on event "" "Consumer" enters state "Waiting_For_Supply" "Producer" transitions from state "Waiting_For_Demand" to state "Sorry_Sold_Out" on event "" "Producer" enters state ”Sorry_Sold_Out" Figure 6.30: Trace data from Spin processed into l'nin'ian-oriented report 107 SYSTEMCLASS : Producer : Consumer OK I u E demand i supply 1 ll--- 1‘ E demand . ', supply 2 <___demand supply 3 demand supply 4 demand supply 5 l E demand , l l ill fill—ill ill _-___-__-________.__________-.__._-_-7\__7\._. Figure 6.31: Sequence diagram corresponding to events depicted in Figure 6.30 108 Chapter 7 Validation: Industrial Case Study This chapter overviews the Adaptive Cruise Control project [77], which we obtained from Siemens Automotive, and presents the results of a case study [40] we performed in order to validate our approach. Recently, this type of system was presented as a central part of an automotive collision avoidance system [78]. This chapter discusses how the system has been modeled with UML, analyzed via the (generated) formal model, and analysis results visualized in terms of both the original UML diagrams and automatically generated sequence diagrams. Results include detection of incon- sistencies between diagrams using static checking, detection of an error on a guard using simulation and visualization, and deadlock detection in a critical brake scenario using model checking and visualization of the counterexample. These discoveries led to several refinements of the UML model. 7.1 Adaptive Cruise Control Project Overview The Adaptive Cruise Control uses radar and an engine control module to control a car’s speed when a vehicle, called the lead vehicle, is encountered in front of the car. When it detects a lead vehicle, Adaptive Cruise Control re-commands the engine control module to match the lead vehicle’s speed. The trail distance behind the lead 109 vehicle is specified as the distance the lead vehicle travels in a given amount of time (usually two seconds). If the Adaptive Cruise Control-equipped car closes to within 90% of the specified trail distance (called the safety zonel) behind the lead vehicle, an audio warning must be sounded and the cruise disengaged. Otherwise, the system must match the speed of the lead vehicle while maintaining a trail distance close to the specified optimum trail distance, but never less than the safe distance. Speed matching should continue until either the lead vehicle moves out of the radar’s range (by speeding up or turning) or until the car’s driver applies the brakes. Figure 7.1 depicts the most common situations. Line 1 defines the various zones the control algorithm uses; Appendix D, page 248, provides more details. Line 2 depicts the radar acquiring the lead vehicle at about 400 feet, the range of the radar, at which time a periodic calculation is initiated to determine how long to maintain the current cruise speed. During this time, the car is in the closing zone. As soon as the relative speed and distance calculation determine coasting should be initiated, the system commands the engine control module to match the speed of the lead vehicle. The lead vehicle’s speed is easily determined from two or more distance samples and the car’s current speed. Because the car has inertia, the command to set the engine to a slower speed effectively results in the car decelerating until it assumes the correct trail position as shown on lines 3 and 4. Finally, line 4 shows the car having achieved the proper trail position of approximately two seconds behind the lead vehicle. If the radar loses the lead vehicle (e.g., vehicle turned or the car driver changed lanes), then the initial cruise speed is resumed. If the system determines that the closing speed is too fast, such that a collision is unavoidable without driver action, then it must produce visual and audio warnings, but not disengage the system. This behavior allows the driver to change lanes without 1The safety zone is approximately 1.8 seconds of lead vehicle travel, or approximately 185 feet at 70 miles per hour. While this distance between vehicles may appear small, human drivers often use much smaller trail distances. 110 Desired trail distance Closing zone ¢——> A Safety zone Coast zone / I” <———> 1' l (if Q H4 \ ‘ \ Trail distance anywhere in here. Q About 400 ft - acquires target vehicle. V aw Starts coasting to match speed 3 ‘” ‘ l . ' ' A —...- V Safe zone Maintain proper trail distance - speeds match This is what we want 4. Closing speed too high. 5. 4* Can t achieve trail. ll _:___ Issues warnings to avoid this condition 6. Figure 7.1: Common situations the Adaptive Cruise Control system must handle. 111 V‘ . I. r I A a pr“"‘V'y. .‘l r, u; I‘Hr ' e 'v .“ ¢ l \‘ 4'. ‘."'\.(‘.-.l‘ .4 “ ‘Liv, .«fi ‘ '. “is l‘.“ 4‘ ~. ~ ‘F. I in.“ .‘ 5. x. ‘. l r; - ‘- ‘ \ 15"}. e. .- 'v «“‘ . ' r ‘.5‘ ‘VP ‘ .— ,m .5 ' ..l ‘ . :C‘ ”(if C §w- ‘ ‘- I \j ‘F' A «‘JP‘fP‘ . :l‘ "‘b \ affecting the current cruise speed. Such a situation is shown on line 5 (Figure 7.1). The system will disengage only when the safety zone is entered, or when the driver applies the brakes. Otherwise, all unsafe conditions result in visual and audio warn- ings to the driver, line 6. (The preceding definitions are summarized in Appendix D, page 248.) 7 .2 UML Modeling for Case Study After discussing prose requirements with project engineers, we created an initial model that supports the main functionality of the system in the absence of exceptional be- havior. The motivation for this approach is to establish and rigorously analyze normal operation of the system, and to add exception cases as later refinements. The initial UML diagrams created to model the system call for the Adaptive Cruise Control- equipped car to detect a slower-moving lead vehicle, calculate the appropriate trail distance, close on the lead vehicle, and decelerate to match the lead vehicle’s speed. The system also warns if collision is imminent and disengages the system when the safety zone is violated. Exceptional behavior, such as the lead vehicle accelerating, de- celerating, turning, or changing lanes, the driver changing lanes, applying the brakes, or turning off the cruise control, or the radar losing the target, is not examined in the initial version of the model. Furthermore, based on discussions with project engi- neers, several abstractions were made in order to make the model tractable for model checking. These abstractions are noted in the following paragraphs. The initial class diagram for the Adaptive Cruise Control system is shown in Fig- ure 7.2 (portions highlighted in bold will be discussed in Section 7.3). In our modeling approach, each class has a state subdiagram that describes its behavior. Additionally, a system is represented by a _SYSTEMCLASS_ class that is an aggregate of classes representing its main components, and a special class, Environment, that represents 112 the context or the environment for the system and can provide external stimuli to the system. As shown in Figure 7.2, the three main classes that comprise the Adaptive Cruise Control system are Control, Car, and Radar. (Appendix D, page 248, contains a detailed explanation of these classes’ attributes and signals.) Sensors, actuators, and the target vehicle are not represented explicitly but have beenabstracted. The Car reports its current speed on request, and the Radar (for modeling purposes) calculates the distance to the target based on the Car’s speed and the target vehicle’s speed (represented in the model as attribute vt of Radar) rather than obtaining actual radar samples. Control accepts input from the driver (represented by the Environment) either to set the desired cruising speed by activating the Radar and controlling the throttle via adjustments to the Car’s speed, or to disengage the system in the event that the driver applies the brakes. Once the Radar has been activated by the Control, it continually simulates scanning for a target and informs the Control of the distance to the target. For modeling purposes, the Radar sampling rate is assumed to be once per second.2 The Adaptive Cruise Control-equipped Car continually adjusts its speed to match the desired speed as calculated by Control. The initial state diagrams for the Car and Radar classes are shown in Figures 7.3 and 7 .4 respectively (portions highlighted in bold will be discussed in Sections 7.3 and 7.4.1). Recall (Chapter 2) that the UML dynamic model or state diagram is based on Statechart [62] conventions and describes the dynamic behavior of objects. Ttansitions are labeled with an (optional) event followed optionally by a guard, an action list, and a message list. Figure 7.3 describes the behavior of the Car class, which abstracts the speed management functionality of an Engine Control Module. There are four concurrent 2The radar sampling rate was not specified in the Adaptive Cruise Control requirements [77]. Experimentation with more frequent sampling rates exceeded available memory for model checking without clear benefit. 113 ackradar(): void brakes(): void carspeed(int): void dist(int): void lost(): void set(): void target(): void setspeed(int): void unset(): void getv(): void getspeed(): void _SYSTEMCLASS_ . cars: int = 0 stimulates Environment ready(): void 3? i l a: int = 15 closing: bool = O setspeed: int tinc: int = 1 tmin: int = 2 v: int vc: int vt: int Hxl: int x2: int xcoast: int Radar xhit: int Car v: int 211 int setv: int = 1100 vc: int 221 int realv: int = 1100 vt: int = 900 ackcar(): void car(): void x: int = 4500 tmode: bool control throttle ackcontrol(): void ackcar(): void on(): void off(): void carv(int): void acksys(): void sample speed l monitor target Figure 7.2: Class diagram for Adaptive Cruise Control 114 i r Composite_Wrapper \ pd. \. l l y : E carv[]/ earl \‘ l __ r i I ( entry/send(Radar.carv(realv))/l getv[realv ‘ setv]/ : l l ; getv[realv < setv]/rea1v := realv +15; : : realv := rnin(realv,setv) : ' l i getv[realv > setv]/rea1v := realv -15; l : realv := max(realv,setv) E ' l ' l i ( carO \ “_SYSTEMCLASS_.ready. i l\ I, If """"""""""""""""" fifiéétééfici """""""""""""""""" ‘x, I I : “_SYSTEMCLASS_.ready _f—j—J setspeed(setv)[]l : l‘ . ' l car3 "Control.ackcar l f """""""""""""""""""" assesses """""""""""""""" ‘x, l l : .A_SYSTEMCLASS_.ready 4 getspeedll/ : l car A ' .\\ ' l Control.carspeed(realv) XI ,x’““"""“"“"""Beas§ei """"""""""""""" ‘x, l I ' A SYSTEMCLASS .read / ' i &— " y 7‘ car5 j unset[]/"Control.ackcar E \ I ______________________________________________________ Figure 7.3: State diagram for Adaptive Cruise Control class Car 115 elm [~tmode & x <= 400] /tmode := 1 ackcontrol[]/ "Control.target "Control.dist(x) r4 [tmode & x > 400]/" ControlJost l r3 entry/v:= vc — vt [~tmode & x > 4001/ i entry/X == X - V \ [tmode & x <= 400]/ "Control.dist(x) r_ack carv(vc)[]l ackcontrol[]/ f r1 ] ) kentry/send(Car.getv on[]/"Control.ackradar off[l/tmode := 0 1 off[]ltmode := 0 off[]ltmode := 0 I r_Off . “_SYSTEMCLASS_.ready off[]l Figure 7.4: State diagram for Adaptive Cruise Control class Radar 116 partitions (delimited by dashed lines) to handle the main functionality of the Car. Partition updatex continually adjusts the car’s speed (realv) to match the desired speed as calculated by Control (setv). The rate of change is specified as 1.5 feet per second (the distance scale for the model is tenths of a foot to give the Control algorithm enough distance samples to be effective3). Partitions updatespd and DOGE’I‘SPD receive the desired speed from Control and send the current speed to Control, respectively. Partition DOUNSET handles an unset message from Control, indicating that the system has been turned off. Figure 7.4 (page 116) depicts the behavior of the Radar class. The Radar is off until activated by the Control. Rather than modeling actual radar samples, which would involve beam-intensity calculations and the possibility of losing the target, target acquisition is represented in the model by the distance x to the target becoming less than 400 feet (the range of the Radar), when the boolean flag tmode is set to true. The Radar continually performs distance calculations and, after target acquisition, informs the Control of the distance to the target. We did not include multiple iterations of the Control state diagram in this chapter; however, the final refinement of the diagram is included in Figure E2 in Appendix E, page 254. (The corresponding Promela code for the Control class and its state diagram is included in Appendix F, page 257.) For discussion purposes, the initial behavior of Control is captured by Figure E.2, minus the dashed and bold transitions which were added as later refinements. The Control accepts a set message from the environment, queries the Car for its current speed, and activates the Radar. After a target is acquired, Control receives distance samples and begins periodic calculations for the zones described in Figure 7.1, line 1 (page 111). 3Experimentation with finer distance scales exceeded available memory for model checking with- out clear benefit. 117 7.3 1 . v1 971‘\ A .... e v p deg}. I y . "t' .‘V r, A.l' . ‘1 ‘ _ l ‘\h r“ 'Y "' 4.. ' . ,fl ~»~. " k..i.‘ 9 . '2‘" ‘1 v. .. if Halt' 8: \ ‘ ‘ G.\ll l”.v ‘ v ..“ ., . ‘ Y‘. .... 'G.‘(- ‘r ’ I ’. i-‘l, r‘ in ‘. k I All i; 3““ 1 Lu‘“ .‘l~,. "AA“ \1 :n’» “.l !- «Irzd - ..r4 1 s ._ . -lJ‘.“'y‘ .“ C1 :\. A \ ~‘ ‘ x" \I‘ . ! "'Afrf'l 7 .3 Structural Analysis In this section, we briefly describe a few subtle structural errors detected by MINERVA and Hydra, using visualization techniques to highlight the source of the errors. In the case study, the tool suite detected that an instance variable setspeed was included in the Control class but was not used, and that instance variable setspd was used in the state diagram for the Control class but was missing from the Control class (this error, if propagated to the Promela model, would cause a syntax error in Spin). Visualizations for these two problems within MINERVA highlighted the class Control and its instance variable setspeed as shown in bold in Figure 7.2 (page 114), and also highlighted transitions and states in the state diagram for Control that used the instance variable setspd (not shown). The actual error was due to the misspelling of instance variable setspd in the Control class that resulted in an inconsistency between the class diagram and the state diagram for the Control class. Structural analysis also detected that the event carv was used on a transition in the concurrent partition updatex of the Car state diagram (Figure 7.3, page 115), but there was no class that sent the signal carv to class Car anywhere within the model. As shown in bold in Figure 7.3, MINERVA highlighted the transition using the signal care in the updatex partition. Instead of the signal carv, the developer meant to use the signal getv, a signal from the Radar requesting the current speed of the Car. While this developer error, if not corrected prior to Promela generation, would likely be discovered later during simulation or model checking with Spin when deadlock occurred in state carO of the updatex partition, determining the exact cause of the problem and automatically tracing it back to the diagrams would be difficult due to its subtle nature. 118 ‘ Y‘L‘ '-aal " ‘. r ‘ I «1 ll:",:: &« . . . . 1 ft" . l V II.— “’A.“1 ‘V Riel». \~ :4L‘l C. "v ‘ylfit r1 . 7 .4 Behavioral Analysis We use Spin in either simulation or model-checking mode to perform behavioral anal- ysis of UML diagrams via their automatically generated formal model. MINERVA’s visualization techniques playback simulation and counterexample traces within UML diagrams, facilitating understanding of behavioral analysis results. Section 7.4.1 illus- trates (via the Adaptive Cruise Control example) how simulation and visualization can be used to detect and highlight errors in UML models. In Sections 7.4.2 and 7.4.3 we model check several requirements-based properties against the Adaptive Cruise Con- trol model to attempt to detect counterexamples in two situations: first, when the car successfully trails the lead vehicle; and second, when the car approaches the lead vehicle too quickly to avoid entering the safety zone. Finally, in Section 7.4.4, we use model checking and visualization to detect and highlight errors in a refined version of the model that includes the driver applying the brakes. In our approach, we use requirements—based properties and model checking to detect counterexamples in order to validate UML models. That is, we are looking for counterexamples (indicating flaws in a UML model) rather that trying to verify correctness of a model. In this chapter, the phrase “verified successfully” means that Spin did not produce a counterexample in an exhaustive search of the generated state space, while “failed” means that the property did not hold, and Spin did produce a counterexample. The number of transitions explored, which Spin reports as a combination of the number of states stored, matched, and visited during a verification, is a measure of how much work Spin performed. We used Spin version 3.3.3 with the default memory allocation on a Solaris-based Spare Ultra—60 workstation with 238 megabytes of free RAM and 305 megabytes of available swap space on disk. Unless otherwise noted, Spin’s default memory allocation was sufficient for complete coverage of the state space for each property. 119 , \m g, ac. . 2.. lsl" . y ,7 \ .7 1‘» d. \V-K. I. ~ ‘- 4 A V. N. l‘ r‘ 77'. “a“ (a?‘ A. '1 4‘ “‘p; 9 . . l . l 91.5.! ~,' J>l r" .4-‘D- Q ..I '1‘. v t“ -k. P 'y t l' t: L: '~. l ‘. t‘ J G ,":",-.r -.di 1;: - J 7 .4.1 Simulation of Preliminary UML Diagrams Simulation revealed an error in a constant used in a guard on several transitions in the Radar state diagram. During initial simulation, the model ran until the Radar issued a target message indicating that a vehicle had been detected at (presumably) about 400 feet (the situation depicted in Figure 7.1, page 111, line 2). However, Control then immediately raised an alarm that the car was too close to the target (i.e., had violated the safety zone), and shut the system down. This behavior was unexpected, as the car should have closed with the lead vehicle and achieved proper trail distance. The simulation trace data from Spin was processed by MINERVA to generate the sequence diagram in Figure 7.5 that reveals that the initial distance sent to class Control by the Radar after target acquisition was around 30 feet, which is much too small (the initial distance should have been close to 400 feet, the range of the Radar). Because class Radar generates the target event signifying target acquisition and sends distances to class Control, the state diagram for class Radar was a logical place to look for the problem. The problem was found quickly by reviewing an animation of the Radar state diagram within MINERVA. This diagram is shown in Figure 7.4 (page 116). As mentioned previously, during the design of the Adaptive Cruise Control model we decided that the distance scale would be tenths of a foot, which gives the Control class enough distance samples to be effective without making the model intractable.4 For example, 400 feet in the model is represented as 4000. However, in the Radar state diagram, the guards on state r3 (shown in bold in Figure 7.4) to test whether a target message should be sent were inadvertently coded in the UML state diagram for Radar as 400 instead of 4000. This developer error had the effect of issuing a target message to class Control at approximately 30 to 40 feet, which does not allow 4Using a radar sampling rate of once per tenth of a second and a distance scale of hundredths of a foot causes about ten times more transitions per execution path explored during model checking, exceeding available memory without clear benefit. 120 l l;,'._ ll : Radar : Control : Car SYSTEMCLASS ready I'll Ill ready ready ready d1100 carspee setspeed 1100 ackcar on Twenty (20) exchanges of messages "getv" and "carv" with parameter 1100 have been elided? I: ddfionldag-----I-I-I.> ..... 1 m. m c a c .9. o t a m a m 3 Ha /_\ --l ..r... I- I I ..>.. dell--- getv carvllOO unset ackcar getspeed carspeed 1100 l I l l I I I l l I I l I l I l/ I\ I l I I I I l ~<——— I I F I I l l I I I l I l l I I Figure 7.5: Sequence diagram from simulation. 121 P l 4 E. "I Q r \ - JO- ,I. '5 'y 1“ than-A A .'Y\O« \. " . stung? 6 0,3, ;|\‘ .‘r II._‘"‘~ a, v .1.” ' ‘K v r"‘ ‘-A..‘ ,<‘ .A.‘ l‘i‘l .I. \‘ ‘A n T‘- '-‘. . I . Y Au (,4. - A. ‘t.‘ .. “‘ C: :l' u'Ol. sufficient time for the car to react. When the guards in the Radar state diagram were changed to use 4000, the Promela model regenerated, and the simulation repeated, then the model ran as expected. A target message was sent around 400 feet, and the car closed with the lead vehicle to a distance of 186.5 feet. Afterwards, the car maintained proper trail distance for several minutes of simulated time until the simulation was terminated manually (without an external event, the car would trail the lead vehicle indefinitely). While this error was simple to fix once we detected it using MIN ERVA’s sequence-diagram generation5 and state-diagram animation of the Spin simulation trace data, relying solely on visual inspection of the UML diagrams might have meant that the error would be propagated through the design, coding, and testing stages before being detected. 7.4.2 Model Checking Initial UML Diagrams Recall that this version of the model represents a typical scenario, where the Adaptive Cruise Control detects a slower-moving lead vehicle, calculates the appropriate trail distance, closes on the lead vehicle, and decelerates to match the lead vehicle’s speed. The system also warns if collision is imminent and disengages the system when the safety zone is violated. In this section, we focus on the situation where the initial values for the speeds of both the car and the lead vehicle as well as the initial distance between them ensure that the car does not enter the safety zone. We examine several LTL variations of two requirements in an attempt to detect counterexamples. Requirement: Normally, the car eventually matches the lead vehicle’s speed. When the Adaptive Cruise Control is on and detects a lead vehicle, the re- quirements state that the car should eventually match the lead vehicle’s speed. In terms of the model, this property could be expressed a number of different ways: 5 MIN ERVA’s sequence diagram depicts communication between UML objects whereas Spin gen- erates message sequence charts (MSCs) in terms of Promela processes. 122 ( []( sent(Control.target) -> (1) <>(Car.realv == Radar.vt) ) ) says it is always (U) the case that when class Control receives a target message (i.e., a target has been acquired), eventually (O) the speed of the Car (realv) will match the speed of the lead or target vehicle (Vt as obtained by the Radar). The above property may be modified slightly to hold only after Control receives a set message (i.e., the cruising speed has been set) using Dwyer et al.’s response specification pattern6 with an after scope ( [] (q -> [] (p -> <>s)) ) [43], which says that s responds to p after q: ( []( sent(Control.set) -> (2) []( sent(Control.target) -> <>(Car.realv == Radar.vt) ) ) ) This modification accurately reflects both the requirements and the model of the sys- tem, because the Radar will not issue target messages until after it has been activated by the Control. Finally, we may choose to interpret the property as follows. The algorithm used for calculating trail distance and controlling the speed of the car sets a boolean flag, closing, to true after the car has become close enough to the lead vehicle that the car can begin decelerating. The property ( []( Control.closing -> (3) <>(Car.realv == Radar.vt) ) ) says it is always the case that after the closing flag has been set to true, eventually the speed of the Car will match that of the lead vehicle. These three claims were verified successfully with Spin, exploring approximately 1.14 million, 1.4 million, and 1.08 million transitions respectively. Requirement: Normally, the car should not enter the safety zone. Under normal circumstances, the car should trail the lead vehicle at a safe distance as 6Chapter 2, Section 2.2.4, contains a brief overview of specification patterns [43]. 123 calculated by the Control’s algorithm. At no time should it enter the safety zone, as defined on line 1 of Figure 7.1. This requirement can be expressed as a system invariant ( [](Control.21 <= Control.x1) ) (4) meaning it is always the case that the calculated minimum safe distance from the lead vehicle (21) is less than or equal to the last sampled distance to the lead vehicle (XI). The property is verified successfully in less than 270,000 transition explorations. 7.4.3 Model Checking After Changing Default Conditions The system must warn if collision is imminent and disengage the system when the safety zone is violated. In this section, we focus on the situation where the car approaches the lead vehicle too quickly to avoid entering the safety zone. We modify the UML diagrams used in Section 7.4.2 to adjust some of the initial values (e.g., decrease vt, the speed of the lead vehicle as obtained by Radar), thus creating such a situation. Then we automatically regenerate the corresponding formal model and re-examine Property 4, which falls as expected (i.e., the car enters the safety zone), and examine LTL versions of two related requirements: Requirement: Entering the safety zone disengages (turns off) the sys- tem. Once the car has entered the safety zone, it is too close to the lead vehicle to avoid a collision; so the cruise control must be disengaged. In terms of the UML diagrams, disengaging the system means that the Control class returns to its idle state and the Radar class returns to its r_off state: ( []( (Control.x1 < Control.z1) -> (5) <>( in(Control.idle) & in(Radar.r_off) ) ) ) This property is verified successfully in less than 220,000 transition explorations. Requirement: If collision is imminent, yet the car is still outside the safety zone, then do not begin disengaging the system until the car enters 124 the safety zone. We say a collision is imminent if the Control algorithm determines that a collision will occur without action on the driver’s part. However, the Control will not begin disengaging the system until the car enters the safety zone so that the driver may change lanes without slowing down. We can express this requirement using Dwyer et al.’s absence pattern with a between scope ( I] ((q 85 !r & <>r) —> (!p U r)) ) [43], which says that p is false between q and r: ( []( ( (Control.xl < Control.xhit) & (6) ~(Control.x1 < Control.zl) & <>(Control.x1 < Control.zl) ) -> ( ~(in(Control.alloff) ) U (Control.xl < Control.zl) ) ) ) where xhit is the calculated distance from the lead vehicle such that if the car were that distance behind the lead vehicle and began decelerating immediately, it would still hit the lead vehicle. This expression says that the Control will not enter its alloff state (i.e., will not begin the process of disengaging the system) between the time that collision is imminent, yet the car is still outside the safety zone, and the time that the car enters the safety zone. The property is verified successfully in approximately 342,000 transition explorations. 7.4.4 Model Checking New Driving Scenarios All of the preceding requirements-based properties were checked against the initial version of the Adaptive Cruise Control UML model (in two different configurations), which uses only one event external to the system, set, sent by the Environment to simulate the driver pressing a button on the steering column to activate the cruise control. The scenarios involving other external events, such as the driver applying the brakes, represent exceptional behavior and thus were not reflected in the original UML diagrams. We now refine the initial Adaptive Cruise Control UML diagrams, 125 specifically, the state diagram for Control that ultimately handles the brakes event, to accept a brakes message issued by the Environment, thus simulating the driver applying the brakes. These refinements are shown as dashed transitions in Figure E2 in Appendix E, page 254. In order to focus our analysis efforts, we study the situation of when the brakes are engaged after the cruise control has been activated. After regenerating the formal model, we examine the following requirement: Requirement: Brakes disengage the system. If the brakes are applied while Adaptive Cruise Control is controlling the speed of the car, then the requirements call for turning off the cruise control and radar. In terms of the UML diagrams, complete disengagement of the system is represented by the Control being in its idle state and Radar being in its r_off state. ( []( sent(Control.brakes) -> (7) <>( in(Control.idle) & in(Radar.r-off) ) ) ) Verification of the property failed initially, because the system model deadlocked before Control could reach its idle state. State diagram animation and sequence diagram generation within MINERVA using the trace data from the counterexample given by Spin illustrated that Control (Figure E2) had stopped in state caroff after the following sequence of events (shown in the generated sequence diagram in Fig- ure 7.6). Upon entry to state calc, Control issued a getspeed message to the Car to request its current speed, but before the Car had responded with a carspeed message, a brakes message arrived. The brakes message caused the Control class to enter its caroff state. A carspeed message, the response from the Car, was then at the top of the message queue for Control;7 however, no transition from state caroff handled message carspeed. The Control class deadlocked in state caroff. After an addi- tional transition was added to state caroff to handle the carspeed message (shown in bold in Figure E2) and the Promela model was regenerated from the updated 7Recall that McUmber’s formalization [31] uses queueing semantics. Spin outputs queue contents at the end of a verification run. 126 UIVIL diagrams, the property was verified successfully, although the verifier had to be recompiled with the option -DMA=632 (suggested by Spin) when the default mem- ory allocation proved to be inadequate. The verification explored approximately 3.9 million transitions. 127 SYSTEMCLASS : Car : Control : Radar : * m I I The six (6) "ready" messages have been elidedIPI I I I I setI A! i i i I. I I I getspeed I I I I carspeed llOO >I I I fi /I l l I setspeed 1100 I I i ' ackcar ' I : I s . | l l on I I I I >l l I I I : I 'E ackradar I I l< getv J I l carv 1100 \I 5 [E m 4 I I carv IIOO \I I r r /I I i, getv I I I carv I100 \I I h M /1 l l ' target I I I I ackcontrol I I I l \l i i i d' 3900 Ii : : K—-— '5‘ ——-l '.< L dist 3900 I I I I I ackcontrol I I I s )1 I I acksys I \I I I ' ’l : a 86W : I I carv “00 \I l h I /l I I IE dist 3700 l :4 I dist 3700 I l r\ I l I I ' getspeed I I I I carspeed 1100 35 I E I [I ackcontrol \I I I acksys I :I I I< getv [I I I carv I100 \I I r I /1 Elided "dist". "dist", "getspeed", "carspeed". "ackcontrol . acksys", "getv". "carv" sequenc for distances 3500 and 3300 (350 and 330 feet. respectively). 3 -—1 i l l I I I ' l , . I I . IE dISI 3100 i I, I dist 3100 I I l\ l l l I I E getspeed I I . brakes . r I : > ' ' I I acksys I J I I I all :I I I r /'I I I unset I I I I carspeed 1100 SI I l C ’l ' I I ackcar >I I I l /l l I I I l l l I I Figure 7.6: Sequence diagram representing counterexample. 128 e \‘V— __ ,r,o' “R.“ ‘7 .3 q ‘.‘LP~ k k.) If; I‘M; \ “u“ NI FM“? . Inn” I A “ ..;§’V-‘ \ ’ Ilzl'b v . ‘ ‘ ‘L‘I‘ ”N _. u - t \.‘ T‘ y 0', " \v +113 5. Y1!» ‘iI‘L‘ ._(“\]\,' j ‘ A‘) * . ‘ II 4 ‘I L. I; 1.}- Q“ (“in .4.) C ““ N :I “ \‘I‘L ] )‘r sani‘m ‘ ".I"":“ ..‘II “is Chapter 8 Reflection: Cost and Applicability In this chapter, we reflect on our approach to validating embedded systems require- ments. Specifically, we examine two aspects of the approach: ( 1) the cost of instru- menting the formal model in order to enable UML-oriented visualization, and (2) the potential applicability of the approach to other application domains. 8.1 Cost of Instrumentation In this section, we examine the cost of the visualization aspect of our overall approach to validating embedded systems requirements. First, we overview our instrumentation-based approach to UML-oriented visualization. Second, we define the cost of this instrumentation in terms of the change in the size of the formal model’s state space. Third, we demonstrate the effect of instrumentation on formal model derivation, formal model internal representation, and formal model state space size using the Producer— Consumer model from Chapter 6 as an example. Fourth, we measure the cost of our instrumentation-based approach to UML-oriented visualiza- tion as applied to the Adaptive Cruise Control industrial case study from Chapter 7. Fifth, we present general conclusions regarding the cost of the approach and outline potential cost-containing enhancements to the approach. 129 8.1.1 A5 sin, ivy l~ . Cathy 9T ii‘fITdf («if A.‘; 1 5" ‘ ‘le ‘iit ‘ I. "i V ---.. Ll .d‘l ,r 8.1. 1 Overview As shown in Figure 8.1 (reprised for the reader’s convenience from Figure 4.1 in Chapter 4), our overall approach to model development and analysis comprises both a model development and analysis framework [40] and an existing formalization frame- work [31, 33] that derives a formal (target language) model from a semi-formal (UML) one according to mapping rules. In this section, we focus on the portion of our in- tegrated frameworks shown in Figure 8.2(a). In Figure 8.2(b), the formalization framework is instantiated with Hydra [31, 33] and McUmber’s Promela mapping rules [31, 33], while the model development and analysis framework is instantiated with our graphical editor/ visualization environment MINERVA [47, 50, 51, 52, 40] and the Promela analysis tool Spin [69]. Figure 8.2(b) illustrates that a set of Promela mapping rules F pROM applied to a UML model u results in a derived Promela model p. In other words, FPROMO‘) 2' p. (8.1) Also shown in Figure 8.2(b), our model development and analysis process applies the behavioral analyses of Spin, A 5p, N, to such a derived Promela model p. Results of these behavioral analyses applied to p, denoted as 7',,, take the form of a trace through the state space of p. In other words, ASP1N(FPR0M(U)) = ASP1N(P) = Tp- (8-2) Part of our model development and analysis process includes a mechanism for visualizing behavioral analysis results (e.g., rp) in terms of the UML model u from which a formal model (i.e., p) was derived. For example, Chapter 6 describes several UML-oriented visualizations, including state diagram animation, sequence diagram generation, and collaboration diagram generation and animation. In order to enable various UML-oriented visualizations, information about a UML model itself (e. g., in— 130 -.—‘-.——-o—- l l P. O n o, g—r7 172 P"; ’1 . O - DU "(4 l‘ “‘ v / Prose requirements User commands l l l l I l ------ Analysis results (human-readable) User input for graphical diagram(s) Graphical Editor & Visualization Environment Intermediate representation of diagram(s) l Translator Mapping rules for formal language Formal model Formal Language Analysis Tool(s) Analysis results (raw) Analysis Result Processor Structural Analysis: Perform intra- and inter- diagram consistency checks prior to formal model generation. Formal Model Generation: Output graphical diagram(s) to intermediate representation, and generate formal model according to mapping rules. Formal Model Analysis (Behavioral Analysis): Perform syntax and semantics checks on formal model, and perform tool-specific analyses such as simulation or model checking. Analysis Result Processing: Convert raw analysis results into human-readable reports or visualization instructions. Figure 8.1: Model development and analysis framework encompassing formalization framework (reprised from Figure 4.1 in Chapter 4) 131 Graphical Editor & Visualization Environment Intermediate representation of diagram(s) Hydra Mapping rules for Promela Translator Mapping rules for formal language F PROM (suonannsui uonezuensin) sunsal sisfilnuv P Formal Language A Analysis Tool(s) SPIN SPIN Analysis r results (raw) P ., L, Analysis Result Processor Analysis Result Processor (a) Portion of integrated (b) Portion of integrated frameworks, frameworks instantiated Figure 8.2: Portion of integrated frameworks from Figure 8.1 examined in this section 132 farm-a: ix must in Beta 11>} Morn... :.t‘ . taiiéi“ H) "Y';v- ‘ lj\l“‘.!‘ ‘ 7: \l"">- '1' _j‘fl; End. ‘1‘ m, . ..‘ &cie.l‘d‘ 1‘ ‘jlflllg I ] L ~ir- " L . «L rgifil'r .‘ _, l i Prl‘i‘y J-l‘. , ‘ G .1 Sin" formation about when a UML state is entered or when a UML transition is taken) must be present in, or able to be inferred from, a formal model derived from it. Because formal languages in general have no concept of UML, UML-model-specific information must either be encoded in formalization rules from the beginning (poten- tially expensive) or added to a formal model during the translation process, ideally only when needed. For example, McUmber’s Promela formalization rules [31, 33] take advantage of Promela’s built-in queueing mechanisms to handle communication between Promela representations of UML state machines. Queue exchanges appear in and can be extracted from Spin’s analysis results. However, a Promela model de- rived with McUmber’s rules does not track which UML transition is currently enabled during execution. Therefore, such information does not appear in Spin’s analysis re- sults. Thus, McUmber’s rules enable UML sequence diagram generation (message exchange), but not UML state diagram animation. To enable UML state diagram animation for a model using McUmber’s rules, information about when a UML state is entered and/ or when a UML transition is taken must be added to the formal model during the translation process. Our approach to enable UML-oriented visualization has two parts. In the first part, we push information about a UML model not already encoded in formalization rules into the formal model derived from it as part of the translation process. This information then manifests itself in the results of analyses performed on the formal model. We depict this information as an asterisk (*) in Equations 8.3 and 8.4, which are refinements of Equations 8.1 and 8.2, respectively. Equation 8.3 states that a set of Promela mapping rules F p R0 M applied to a UML model augmented with information about u, u*, results in a derived Promela model augmented with information about u, 19*. Equation 8.4 states that results of Spin’s behavioral analyses (Aspm) applied 133 ID p‘. dt‘ In the SH retrieves C'Oll's'E’I'IS 1t. Figup- n. i . VlU‘ '1' -. '* “(11126, to p“, denoted as rp-, take the form of a trace through the state space of p*. FPROMl‘u“) = 10* (8-3) ASPIN(FPROM(U*)) = ASPIN(P*) = Tp‘ (8-4) In the second part, a mechanism (i.e., the Analysis Result Processor in Figure 8.2) retrieves such information about u, u*, from the (raw) formal analysis results and converts it into visualization instructions in terms of the UML model (denoted as 2),, in Figure 8.2(b)). Because different formal analysis tools have differing outputs, this mechanism is specific to the formal analysis tool used. Equation 8.5 illustrates the visualization mechanism specific to Spin, V3 p m, applied to Spin’s analysis results rp-. VSPINMSPIMFPROM(137)) = VSPIN(ASPIN(p*)) = VSP1N(Tp’) = Uu (8-5) We call this approach to enabling UML-oriented visualization the breadcrumb ap- proach, likening it to Hansel dropping breadcrumbs in the forest to mark the way home [79]. The breadcrumb approach currently offers three options for pushing diagram in- formation from a UML model into the formal model derived from it (in the sequel we will refer to these options as breadcrumb options). We may choose to augment the formal model with information about 0 UML states only, 0 UML transitions only, or 0 both UML states and UML transitions. Note that the default is to instrument no additional UML diagram elements. We call this version of the breadcrumb approach naive because it affects an entire set of 134 UML elements (e.g., all UML states of all state diagrams in a model) rather than just a select subset of UML elements (e.g., a group of user-identified “interesting” transitions of all state diagrams in a model, only those UML states referenced in a requirements—based property to be checked against the model). In the case where we instantiate our model development and analysis framework with the formal analysis tool Spin and our Spin-specific visualization mechanism, these breadcrumb options transparently instruct MINERVA to add special print ac- tions to UML states and/ or UML transitions prior to their translation to Promela. Hydra translates such an action added to a given UML state into a printf statement in the corresponding Promela model indicating that the UML state has been entered. Similarly, Hydra translates such an action added to a given UML transition into a printf statement in the corresponding Promela model indicating that the transi- tion has been taken. The Spin-specific visualization mechanism then searches Spin’s analysis results for the output of these printf statements (i.e., the breadcrumbs). 8.1.2 Defining Cost One of the most important issues in model checking is the size of a formal model’s state space [70] (measured as the number of unique states in the state space). A seemingly small change to a formal model (e.g., adding a printf statement) may have a large effect on the size of its state space. Therefore, we must measure the cost of the naive breadcrumb approach. As part of its analysis output, Spin reports the number of unique states in a derived Promela model’s state space (i.e., the size of the state space). For each of the three breadcrumb options applied to a given UML model, we measure the change in the size of the corresponding derived formal model’s state space. To obtain baseline measurements for a given UML model, we derive a Promela model from the UML model without using any of the breadcrumb options and then use Spin to perform a state space exploration of this Promela model. We 135 use as ti PDT 3 P: \ l o -- - _V‘fj (‘ ,4“ ).i_ ‘LLI.‘ WEN.“ 1‘- 1~ 7 i illr‘ (Ki-z: "in .‘- f. al.?) (N: and a n» - o illhl l 4L.‘ ‘ 1: tin“ . ""“F'lFT use as a baseline the number of unique states in this Promela model’s state space. For a Promela model derived with any one of the breadcrumb options, we measure the change in the size of the state space as (sizebrmdcrumb, - Sizebasezz‘ne) (8.6) Slzebaseline where sizebrmdaumbi is the size of the state space for a formal model generated with the breadcrumb options 1. UML states only, 2. UML transitions only, or 3. both UML states and UML transitions; sizebaselme is the size of the state space for a formal model generated with no bread- crumb options; a positive result indicates an increase in the size of the state space; and a negative result indicates a decrease in the size of the state space. 8.1.3 Producer- Consumer Example To demonstrate the effect of each breadcrumb option on formal model derivation, formal model internal representation, and formal model state space size, we use the Producer-Consumer example from Chapter 6. For convenience to the reader, the (final) UML diagrams for the Producer— Consumer example are reproduced here (Fig- ures 8.3, 8.4, 8.5, and 8.6). Recall that the role of the SYSTEMCLASS. is to instan— tiate the other objects of the system, as indicated by the “new” entry actions in the states of the _SYSTEMCLASS_ state diagram in Figure 8.4. Effect on formal model derivation. From the UML model of Producer- Consumer, we derive the corresponding baseline Promela model (generated with no 136 _SYSTEMCLASS_ OK(): void Producer Consumer limited_ed: int = 5 num_made: int = O edition_num: int = 0 supply(int): void demand(): void Figure 8.3: Class diagram for Producer- Consumer breadcrumb options), as well as Promela models generated with each of the three breadcrumb options: UML states only, UML transitions only, and both UML states and UML transitions. The Promela code for each of these four models is listed in Appendix G (page 266) in Sections (3.1, G2, G3, and G.4, respectively. Breadcrumb options that transparently add print actions to a UML transition cause printf state- ments to appear in the generated Promela code for that transition (e. g., Section (3.3, page 278, line 93; Section G.4, page 285, line 107), while breadcrumb options that transparently add print entry actions to a UML state cause printf statements to appear in the generated Promela code for that state (e.g., Section (3.2, page 272, line 32; Section G.4, page 285, line 99). Effect on formal model’s internal representation. Recall (Chapter 2) that McUmber’s Promela formalization [31, 33] maps each UML state diagram into a set of proctypes (fiat UML state diagrams, such as those in the Producer- Consumer ex- 137 ! Create_Producer entry/new(Producer) OK[]/ Create_Consumer entry/new(Consumer) OK[]I Figure 8.4: State diagram for Producer— Consumer class _SYSTEMCLASS- demand[num_made < limited_ed] /num_made := num_made + l “_SYSTEMCLASS_.OK f ._ KWaiting_For_Demand1 []/"Consumer.supply(num_made) (Advertise I [num_made >= limited_ed]/ @rry_80ld_0© Figure 8.5: State diagram for Producer- Consumer class Producer 138 “_SYSTEMCLASS_.OK Have_Money_Will_Spend supply(edition_num)[]/ []l"Producer.demand Waiting_For_Supply Figure 8.6: State diagram for Producer- Consumer class Consumer 139 ample, are mapped into a single proctype each; z'.e., a singleton set). Spin internally converts each proctype into a finite-state machine (FSM) with uniquely numbered states and offers an option to display it. For example, the FSMs for the baseline Promela model derived from the UML state diagrams of the _SYSTEMCLASS_, Pro- ducer and Consumer are shown in Figures 8.7, 8.8, and 8.9, respectively. Each arc in Figures 8.7, 8.8 and 8.9 corresponds to a Promela statement in the proctype derived from the UML state diagrams of the _SYSTEMCLASS_, Producer, and Consumer, re- spectively. Therefore, when breadcrumb options introduce printf statements into a derived Promela model, each printf statement in a proctype becomes a new arc and state in the F SM for that proctype. For example, the FSMs for the Promela model derived from the UML state diagrams of the -SYSTEMCLASS-, Producer and Consumer using the breadcrumb option “Both UML States and UML Transitions” are shown in Figures 8.10, 8.11, and 8.12, respectively. Note that each one of these FSMS (with instrumentation) has more unique states and arcs than its corresponding baseline FSM (without instrumentation). 140 GGGGGGQQGQQQEGGGGGGG Figul‘e 8.7: Finite state machine for -SYSTEMCLASS- proctype, baseline \ 141 ’e‘e e e eee e e 900 e e e e e e ®$®\: Figure 8.8: Finite state machine for Producer proctype, baseline 142 Figure 8.9: Finite state machine for Consumer proctype, baseline 143 eeeeeeeeoee \ 8* /@ (go eeeeeeeeee E Figure 8.10: Finite state machine for _SYSTEMCLASS_ proctype, option Both 144 6 . Q"? a ®® ff ®®®9®9€3®|®®®®666690@96 8 Figure 8.11: Finite state machine for Producer proctype, option Both 145 @ Figure 8.12: Finite state machine for Consumer proctype, option Both 146 Effect on formal model’s state space size. For each derived Promela model for Producer-Consumer (i.e., one model derived without any instrumentation and one model apiece derived for each of the three breadcrumb options), we then generate and explore its state space with the following commands: 1. spin -a modelname.pr Executes Spin on the Promela model modelname. pr (in this case, the automati- cally generated Promela model for Producer— Consumer with a given breadcrumb option, or lack thereof) with option -a. Option -a generates a verifier, a C pro- gram file called pan. c that when compiled and executed performs an exhaustive verification (i.e., exploration) of the model’s state space according to various run-time options. 2. gcc -o modelname pan.c Executes the gcc (GNU Compiler Collection) [80] C and C++ compiler on the file pan. c and outputs the executable to a file named modelname. 3. modelname Executes the file modelname, performing an exhaustive verification of the de- rived Promela model’s state space (i.e., in this case, checking user-specified assertions, or boolean conditions about the state of the model, and checking for invalid endstates, or states in which the overall model’s execution ends before each proctype has reached its final statement or with non-empty channels). In the Producer-Consumer model, there are no user—specified assertions. The analysis results (contained in Appendix H, page 294) indicate an invalid end- state because at the end of execution, there is still one demand message left in the queue for the Producer. Recall (Chapter 6) that we did not refine the Producer-Consumer model further to handle this final message explicitly. For the purposes of this discussion, we do not consider this invalid endstate an error. 147 The verification generates the reachable state space of the model, a product of the interleaved F SMs of the proctypes of the derived Promela model. At the end of the verification, Spin reports the number of unique Promela states stored, i.e., the size of the state space. The Spin analysis results for exploring the state space of the baseline Promela model and Promela models for the three breadcrumb options for the Producer-Consumer example are shown in Appendix H in Figures H.1, H2, H3, and H.4, respectively. The size of the state space for each model is shown in Figure 8.13. The amount of change in the size of the state space for the Producer- Consumer example, as calculated by Equation 8.6 (page 136), for each breadcrumb option is shown in Figure 8.14 (values have been rounded to two decimal places). Size of State Space Number of Unique States Baseline UML States UML Transitions UML States and Transitions Producer/Consumer Model Figure 8.13: Number of unique (Promela) states in formal model of Producer- Consumer example for baseline and each breadcrumb option 148 Change in Number of Unique States 0.35 0.30 0.3 .9 N u. .° N 0.15 - 0.13 Change In Number of States 9 0.05 - UML States UML Transitions UML States and Transitions Breadcrumb Option Figure 8.14: Cost: Change in number of unique (Promela) states in formal model of Producer— Consumer example for each breadcrumb option 8.1.4 Cost of Instrumentation as Applied to Adaptive Cruise Control In this section, we consider the cost of our approach as applied to two Adaptive Cruise Control UML models from [40]. The models are identical in every way except one. In the first model, the Adaptive Cruise Control-equipped car acquires the lead vehicle as a target, achieves the proper trailing distance, and trails the lead vehicle indefinitely. In the second model, the (constant) speed of the lead vehicle (represented as an attribute in the UML model) is set too low for the Adaptive Cruise Control-equipped car to safely achieve the proper trailing distance. Thus, the cruise—control powers off almost immediately. These models represent a normal or sunny-day and an exceptional or 149 rainy-day scenario, respectively. After generating the Promela model for each scenario, we apply Spin to the Promela models as described in the previous section to obtain baseline measurements for the size of the state space. Figure 8.15 shows the size of the state space for the model of each scenario. Note that although the UML models and subsequently the corresponding derived Promela models for each scenario are identical in every way except the value of the lead vehicle’s speed, the state spaces of the formal models for each scenario differ significantly in size. This difference is explained by the fact that Spin takes into account only reachable states during analysis. The sunny—day scenario exercises a large portion of the Adaptive Cruise Control UML (and thus its corresponding formal) model, including several iterations through a calculation algo- rithm to determine the proper trailing distance and car speed. On the other hand, the rainy-day scenario exercises a much smaller portion of the Adaptive Cruise Control UML (and thus its corresponding formal) model, determining on the first iteration through the calculation algorithm that achieving a safe trailing distance is not possible and shutting down the cruise control. For comparison, we also generate three more Promela models for each scenario, one for each of the three breadcrumb options, and perform analysis with Spin as described in the previous section. For both scenarios, the change in the size of the state space for each breadcrumb option is shown in Figure 8.16 (values have been rounded to two decimal places). The amount of change across all breadcrumb options is slightly larger for the rainy-day scenario. This effect is due to the smaller baseline state space size of the rainy-day model. The baseline state space size is the denominator in Equation 8.6 (page 136), so a similar absolute increase (decrease) in the state space size between two models will yield a greater amount of change in the model with the smaller baseline state space size. We next examine Properties 1 — 4 from Chapter 7 (page 123) against the sunny- 150 Size of State Space 120000 99124 100000 80000 60000 40000 Number of Unique States 20000 831 Sunny Day Rainy Day Adaptive Cruise Control Model Figure 8.15: Number of unique (Promela) states in formal model of Adaptive Cruise Control for sunny—day and rainy—day scenarios 151 Change in Number of Unique States .0 c on + l l l ‘ Change in Number of States 3 o a. _ i ’2 .0 o N O Sunny Day Rainy Day Adaptive Cruise Control Model LCTUNEStat; UML Transit»; IUML Statesfldlransitions 2 Figure 8.16: Cost: Change in number of unique (Promela) states in formal model of Adaptive Cruise Control for sunny-day and rainy—day scenarios 152 day scenario. The first three properties represent different ways in LTL to express the Adaptive Cruise Control requirement that the car eventually matches the lead vehicle’s speed, while the fourth property expresses the requirement that the car should not enter the safety zone. The state space explored in each case is the product of the formal model executed synchronously with the FSM for the given property. The resulting state space size for each exploration is shown in Figure 8.17, while the change in state space size is shown in Figure 8.18 (values have been rounded to two decimal places). Although the state space size of the models for these properties vary widely, the change in state space size across all the breadcrumb options for these models is very similar. Size of State Space 400000 350000« ~ , W e 7 ~ _—_340796_F - - -. -- CF A..- - , , , a--- _v-.__._, , 300000 246536 250000 — 209751 200000 - 150000 - Number of Unique States 100000 4 50000 d Ibopefly'l inopenyiz IhopenyZS inopenyll Adaptive Cruise Control Properties Checked Against Sunny Day Scenario Figure 8.17: Number of unique (Promela) states in formal model of Adaptive Cruise Control for Properties 1 — 4 checked against sunny-day scenario Finally, we examine Properties 4 — 6 from Chapter 7 (page 124) against the rainy- 153 Change in Number of Unique States Change in Number of States 9 .o .o .o g 0 O O on . . S3 o N Property 1 Property 2 Property 3 Property 4 Adaptive Cruise Control Properties Checked Against Sunny Day Scenario ll] UML States UML Transitions I UML States and Transitions Figure 8.18: Cost: Change in number of unique (Promela) states in formal model of Adaptive Cruise Control for Properties 1—4 checked against sunny-day scenario 154 day scenario. Property 4 expresses the requirement that the car should not enter the safety zone, which produces a counterexample when checked against the rainy-day model. Property 5 expresses the requirement that entering the safety zone disengages the system, and Property 6 expresses the requirement that when collision is imminent, disengagement does not occur until the car enters the safety zone. The resulting state space size for each exploration is shown in Figure 8.19, while the change in state space size is shown in Figure 8.20 (values have been rounded to two decimal places). The state space size for the model checked against Property 4 is significantly smaller than the other two because Spin detected a counterexample almost immediately and terminated the analysis. Again, although the state space size of the models for these properties vary widely, the change in state space size across all the breadcrumb options for these models is very similar. 8. 1.5 Conclusions Figure 8.21 shows, for all the models measured, the cost for each of the three bread- crumb options as a function of state space size. The breadcrumb option Both UML States and UML Transitions pushes the most information into the formal model, instrumenting both UML states and UML transitions with print actions. As demon- strated in Section 8.1.3, these print actions manifest as printf statements in the Promela model, and as additional arcs in the F SMs for each proctype. Therefore it is not surprising that this option incurs the most cost in terms of the amount of change in the size of the state space for all the models measured (shown in Figure 8.21 as the dotted line). Beyond 100,000 states, the cost for this option drops below 15 percent. The breadcrumb option UML Transitions (solid line) appears the least costly for the models measured, dropping below six percent beyond 100,000 states. As current model checking endeavors may need to handle 1020 states and beyond, six percent is a more practical bound. 155 120000 80000 60000 40000 Number of Unique States 20000 Size of State Space 96043 73172 805 Property 4 Property 5 Property 6 Adaptive Cruise Control Properties Checked Against Rainy Day Scenario Figure 8.19: Number of unique (Promela) states in formal model of Adaptive Cruise Control for Properties 4 — 6 checked against rainy-day scenario 156 Change in Number of Unique States 9 P .0 .... .— —- .° A as on N 9 N Change in Number of States .9 5= .0 o E 8 8 _ .o O u 0 Property 4 Property 5 Property 6 Adaptive Cruise Control Properties Checked Against Rainy Day Scenario IE] UML States I UML Transitions I UML States and Transitions l Figure 8.20: Cost: Change in number of unique (Promela) states in formal model of Adaptive Cruise Control for Properties 4 — 6 checked against rainy-day scenario 157 Breadcrumb Cost 0.35 0.3 - 0.25 Breadcrumb Cost Versus State Space Size T T T T I Y I 50000 1 00000 1 50000 200000 250000 300000 350000 State Space Size 0 Change: UML States I Change: UML Transitions Change: UML States and Transitions — — Log. (Change: UML States) —— Log. (Change: UML Transitions) - - - Log. (Change: UML States and Transitions) Figure 8.21: Cost versus state space size per breadcrumb option 400000 158 In addition to focusing on the UML Transitions breadcrumb option that appears to incur the least cost of all the options, future work may consider various other strategies to limit the cost of the breadcrumb approach while still providing relevant feedback to the user. Three such strategies are outlined below: User-selected elements. A selective approach to instrumentation of UML ele- ments would, in general, incur less cost than the naive approach. To implement this strategy, we would need to add to MINERVA the capability for the user to select which UML elements to instrument and/or to ignore, similar to setting breakpoints in a debugging tool. Elements in requirements-based properties. Automatically instrumenting only those UML states and/or UML transitions involved in a requirements-based property would, in general, incur less cost than the naive approach. Intuitively, the elements involved in a requirements-based property are of interest and should be instrumented. To implement this strategy, we would need to add to MINERVA the capability to automatically instrument the UML states and/ or UML transitions involved in a requirements-based property. Combination strategy. While either of the above two strategies would, in general, incur less cost than the naive approach, the first offers no guidance to users as to which elements(s) to instrument, while the second instruments only a small subset of UML elements of possible interest to the user. A combination strategy would automatically instrument elements involved in a requirements-based property thus giving a starting point for visualization of formal analysis results. However, this strategy would also enable the user to select additional UML states and/or UML transitions for instrumentation in order to extend the focus of visualizations. 159 8.2 Applicability of the Approach to Other Do- mains This research applies UML formalization to enable developers to use automated tools to validate embedded-systems requirements. Specifically, we describe a model de- velopment and analysis framework that integrates an existing formalization frame- work ]31, 33], and a model development and analysis process for a specific instanti- ation of the integrated frameworks (Chapter 4). This process systematically applies the steps of model creation, formal model generation, formal specification transla- tion, model analysis, and visual interpretation of analysis results. In this section, we discuss the applicability of the presented approach to other application domains. Our instantiation of the model development/ analysis and formalization frame- works with tools MINERVA [40, 47, 50, 51, 52], Hydra [31, 48], and Spin [69] in- corporates several assumptions relevant to the embedded systems domain that may preclude the use of the approach for other application domains. These assumptions include the use of state diagrams to model requirements, static model configurations, and object-level concurrency with single-threaded objects. Below, we discuss the ramifications of these assumptions: Use of state diagrams. This approach uses state diagrams to model requirements. Therefore, other application domains that might be able to use this approach are those that typically rely on state diagrams to model requirements (e.g., controllers, reac- tive systems, some user interfaces). Application domains that are not traditionally modeled with state diagrams, such as databases, would not use this approach. Static model configurations. Embedded systems are control systems with static configurations; that is, objects are not dynamically created and destroyed during ex- ecution. McUmber’s Promela formalization rules [31, 33], realized in Hydra [31, 48], 160 make this assumption. Therefore, application domains that typically have dynamic configurations where objects are created and destroyed on-the—fiy, such as user inter- faces, would not use this approach. Object-level concurrency and single-threading. Our approach to modeling embedded systems requirements assumes that each object has a single thread of con- trol, and that all objects in the system execute concurrently. Again, McUmber’s Promela formalization rules [31, 33], realized in Hydra [31, 48], make this assump- tion. Therefore, this approach would not be applied to multi-threaded applications, or applications with many passive objects such as user interfaces. 161 Chapter 9 Extension: A Pattern-Driven Approach to Fault Handling High-assurance systems must deliver their services in a manner that satisfies cer- tain critical properties, which may include fault-tolerance properties [81]. A fault- tolerant system provides a certain guaranteed level of service despite the presence of faults (e.g., hardware failures, environmental anomalies, dangerous or illegal system conditions). This chapter discusses how we can extend our modeling and analysis framework with patterns for handling fault-tolerance requirements. Faults manifest themselves as errors (e.g., a flag indicating a hardware error is set, a value is out of acceptable range), that in turn lead to system failure, i.e., the system deviating from desired or acceptable behavior. The relationship between faults, errors, and failure is shown in Expression (9.1). fault —> error —> failure (9.1) According to Lee and Anderson [82], there are four phases of fault tolerance that, taken together, prevent faults from leading to system failure: 162 1. Error detection. While a fault itself cannot be detected, the presence of a fault generates detectable error conditions. 2. Damage confinement and assessment. Because it is more likely than not that a delay has occurred between the occurrence of a fault and the detection of the offending error condition(s), overall damage to the system must be assessed before recovery is attempted. 3. Error recovery. Recovery techniques bring the system back into a well-defined and error— free state. 4. Fault treatment and continued system service. Detecting an error condi- tion does not necessarily unambiguously identify the fault that caused it (i.e., several different faults may cause the same error condition to arise). Ideally, the particular fault that caused the error condition to arise is identified and treated so that it does not recur. This phase differs from the previous three phases in that it addresses faults themselves rather than their resulting error conditions. In this chapter, we focus on Lee and Anderson’s phase 1, error detection, and phase 3, error recovery or correction. First, we provide an overview of two fault- tolerance concepts, namely error detection and error correction, and introduce three Detector- Corrector Patterns for modeling these concepts in UML. Second, we summa- rize Konrad and Cheng’s object analysis patterns1 [1] for (non-distributed) embedded systems; i.e., templates in the spirit of design patterns [83] that include example UML class, state and sequence diagrams describing structural and behavioral pat- terns common to embedded systems. Object analysis patterns, and their included di- agram templates, guide developers in modeling embedded systems requirements with UML. A given object analysis pattern also includes constraints [53], specification- pattern-based [43] temporal logic templates for properties of interest with respect to 1Object analysis patterns [1] were formerly termed requirements patterns [2, 3, 4]. 163 the object analysis pattern providing their context. These temporal logic templates guide developers in specifying and instantiating requirements-based properties appro- priate to check against a UML model created using the given object analysis pattern. Object analysis patterns and their constraints can be used to drive our model de- velopment and analysis process presented in Chapter 4. Third, because this chapter focuses on patterns for fault tolerance, we overview a specific requirements patternz, the Fault Handler requirements pattern [2, 3, 4], that describes how to incorporate a centralized FaultHandler into an embedded system. While this requirements pattern provides a state diagram template for the ComputingComponent of an embedded sys- tem, it does not give any modeling guidelines for the behavior of the FaultHandler. Therefore, using our previously introduced Detector-Corrector Patterns, we next ex- tend the original Fault Handler requirements pattern with both a revised UML class diagram template and a new UML state diagram template for the FaultHandler. We then extend the underlying formalization framework with semantics for centralized fault handling. Finally, we apply this pattern-driven approach to the Adaptive Cruise Control example from Chapter 7. 9.1 Detectors and Correctors To facilitate the modeling and analysis of fault-tolerance requirements, we propose to explore how the concepts of detectors and correctors from the fault-tolerance com- munity [57] can be used to develop structural patterns for modeling fault-tolerance in non-distributed embedded systems. A detector is a system component that “de- tects” whether some state predicate (i.e., a boolean expression over system variables) is satisfied by the system state [57]. Examples of detectors in embedded systems 2At the time of this writing, object analysis patterns for fault handling were still under develop— ment. This chapter presents preliminary work in revising the original Fault Handler requirements pattern. The overall pattern-driven approach to model development and analysis, first presented in [41], remains the same whether the patterns are termed requirements patterns or object analysis patterns. 164 include comparators, watchdog programs, and exception conditions. A corrector is a system component that “corrects” the system state (i.e., adjusts the values of system variables) in order to satisfy some state predicate whenever it is not satisfied [57]. Examples of correctors in embedded systems include reset procedures and exception handlers. In this work, we model specific types of detectors and correctors as classes in the UML class diagram as shown in Figure 9.1. The detector attribute of a PredicateDe— tector is modeled as a boolean expression over system variables, while the corrector attribute of an ActionCorrector is modeled as a sequence of actions adjusting the val- ues of system variables. Modeling detectors and correctors as classes rather than as data types allows us to model the relationships between them with associations. A detector can be modeled without a corrector, as denoted by the arity of the “corrected by” association in Figure 9.1. Such a detector can be used to prevent a system from entering an undesirable state. Otherwise, a detector can be used together with a corrector that restores the system to a desirable state, as denoted by the arity of the “responds to” association in the figure. The type boolExprString indicates that the value of the PredicateDetector attribute detector is a string that should be parsed as a boolean expression, where the terms are constants, or referencesto attributes from the aggregating class or from other classes in a UML model. Attributes may be com- pared with constants or with other attributes. The type actionSeqString indicates that the value of the ActionCorrector attribute corrector is a string that should be parsed as a sequence of UML actions that adjust the values of system attributes (i.e., attribute assignments or message sends). Because we model detectors and correctors in UML class diagrams as aggregated classes, PredicateDetector and ActionCorrector attributes (detector and corrector, respectively) may then be referenced in the UML state diagram owned by the aggregating class.3 3Recall (Section 2.2.5, page 25) that according to McUmber et al.’s diagram integration conven- tions, 8. state diagram expressing the behavior of a class is said to be owned by the class. 165 1 1 <———responds to Detector Corrector corrected by ____,, 1 0.. 1 PredicateDetector ActionCorrector detector : boolExprString = corrector : actionSeqString = Figure 9.1: Modeling detectors and correctors in the UML class diagram Thus far, we have determined three patterns for modeling detectors and correc- tors in UML. We refer to these patterns collectively as Detector- Corrector Patterns. Figures 9.2, 9.3, and 9.4 illustrate patterns 1, 2, and 3, respectively. In the first pat- tern (Figure 9.2), a detector is modeled without a corresponding corrector. There are no associations between the detector and any corresponding corrector. For example, the PredicateDetector in the class and object diagrams in Figures 9.2(a) and 9.2(b) is not associated with any ActionCorrector. Detectors modeled without correctors are used to prevent entry to a particular state when the error condition detected by the detector is true. For example, in one of our case studies, the Diesel Filter System (DFS) [41, 84] may not enter its cleaning cycle if the current system pressure is below 8,000 or above 10,000 Pascals (Pa). We model this usage in the UML state diagram with a negated detector as a guard on transitions targeting a particular state in order to permit entry to the state when the error condition detected by the detector is false (e.g., the DFS may enter its cleaning cycle if the current system pressure is between 8,000 and 10,000 Pa). The detector is used as a guard on other transitions in order to transition to another state when the error condition detected by the detector is true ( e. 9., when the pressure is above 10,000 Pa, the DFS shuts down). In the example state diagram in Figure 9.2(c), corresponding to the object diagram in Figure 9.2(b), 166 it is undesirable to enter State-w2 when the condition detected by PD is true. There- fore, the condition ! (PD . detector), the negated detector, guards the transition from State_Wl to State-w2 (i.e., if the condition detected by PD is false, then entering state State..w2 is permissible). Additionally, the condition PD.detector guards an- other transition from State_Wl to a desirable state when the condition detected by PD is true (i.e., a state other than State-w2). Class W : Class PredicateDetector PD : PredicateDetector (a) Class diagram (b) Object diagram [!(PD.detector)] State_W2 [PD.detector] t [ State_W3 (c) State diagram Figure 9.2: Pattern 1 for modeling detectors and correctors In the second pattern (Figure 9.3), both a detector and its corresponding corrector are aggregated by the same class. There are associations between the detector and its corresponding corrector. For example, the PredicateDetector and ActionCorrector in the class and object diagrams in Figures 9.3(a) and 9.3(b) have associations between 167 them. These associations relate a particular detector with a particular corrector, since different error conditions most likely require different corrective actions. For example, in the Integrated Starter/ Generator (ISG) [85] project, if the ISG is in running power generation mode, then low battery voltage requires that drive assist be disabled, whereas excessive battery charge requires that the charging system be turned off. This relationship between a detector and its associated corrector carries over into the state diagram, as illustrated in Figure 9.3(c). For illustrative purposes, the transition from State.“ to State_X2 in the state diagram (that corresponds to the object diagram in Figure 9.3(b)) is annotated with the detector PD.detector, as a guard, and its corresponding corrector AC. corrector, as an action sequence. The transition is enabled when the condition detected by PD is true. Firing the transition performs the corrective action described by AC. In the third pattern (Figure 9.4), corresponding detectors and correctors are ag- gregated by two different classes. For example, in the Anti-Lock Braking System (ABS) [53, 86] project, a centralized FaultHandler activates a redundant brake sen- sor when a Watchdog detects that the primary brake sensor has failed. There are associations between the detector and its corresponding corrector as illustrated in Figures 9.4(a) and 9.4(b). These diagrams also show the PredicateDetector PD aggre- gated by object Y, while object Z aggregates its corresponding ActionCorrector AC. In this pattern, the detecting object (e.g., Y) must somehow inform the correcting object (e.g., Z) that a specific error condition has been detected in order to take the appropriate corrective action. In the state diagrams for Y and Z in Figure 9.4(c) that correspond to the object diagram in Figure 9.4(b), this information is imparted via a parameterized signal message that Y sends to Z when the condition detected by PD (via a guard on a transition in the state diagram of Y) is true. The class of object Z must have declared the parameterized signal message, and the parameter error, in the class diagram in order for Z to use message as an event on a transition in its 168 Class responds to [ PredicateDetector ActionCorrector corrected by (a) Class diagram X : Class ~% [PD.detector] / AC.corrector PD : PredicateDetector AC : ActionCorrector (b) Object diagram (c) State diagram Figure 9.3: Pattern 2 for modeling detectors and correctors 169 state diagram. If 2 aggregates more than one ActionCorrector, then there must be more than one transition handling the signal message, with each guard testing the parameter value against known error codes to determine the appropriate transition to fire, and thus the corrective action sequence to perform. 9.2 Object Analysis Patterns and Constraints Konrad and Cheng have identified several patterns to describe requirements for the main elements of an embedded system [1, 2, 3, 4]. Figure 9.5 gives a list of the object analysis patterns4 that have been identified to date with a brief description of each. The complete set of object analysis patterns and their full descriptions are given else- where [1]. In order to address the needs of requirements engineering, they developed a template to describe these object analysis patterns [1, 2, 3, 4] by modifying the orig- inal design pattern template [83]. Such modifications include extending the original design pattern template with a Constraints field [53] that contains specification- pattern—based [43] representations of properties of interest. Object analysis patterns can provide both guidance to novices of embedded sys- tems development for determining the key elements of many embedded systems, and examples of how to model these elements with a commonly accepted diagramming notation, UML. Additionally, object analysis pattern constraints provide a template for instantiating properties specific to a modeled system in terms of the UML dia— grams describing the system. Thus far, the constraints have included representations of two of Dwyer et al.’s [43] most commonly used general specification pattern cate- gories, universality/absence (to capture invariant properties) and response (to capture cause/ effect relationships in system behavior). Preliminary feedback from industrial collaborators indicates that object analy- sis patterns can be an effective mechanism for describing requirements of embedded 4Object analysis patterns were formerly termed requirements patterns. 170 Class_l C lass_2 [ responds to [ PredicateDetector ActionCorrector corrected by (a) Class diagram Y : Class I Z: Class 2 PD : PredicateDetector AC : ActionCorrector (1)) Object diagram I State_Yl ] State_Y2 [PD.detector] / send(Z.message(code)) l State_Zl ] State_Z2 message(error) [error == code] / AC.corrector (c) State diagrams Figure 9.4: Pattern 3 for modeling detectors and correctors 171 o Actuator-Sensor: The Actuator-Sensor pattern specifies basic types of sensors and actuators in an embedded system. In addition, the interaction with the environment via sensors and actuators is one of the main respon- sibilities of an embedded system. Therefore, the pattern also describes how relationships between actuators and sensors and other components in the system can be captured. 0 Communication Link: Due to the growth in demand for distributed real-time embedded systems, communication capabilities are becoming more important. The Communication Link pattern describes how to cap- ture high-level information about communication capabilities offered by an embedded system, such as sending periodic “heartbeat” messages to other systems. 0 Computing Component: Embedded systems have to offer various oper- ational modes as they often function in an environment where a shutdown of the system would lead to a significant loss. In this pattern, various op- erational modes of an embedded system are specified, such as fail-safe modes that a system enters in response to occurring faults. 0 Controller Decompose: This pattern describes how to decompose an embedded system into different components according to their responsi- bilities. It is the foundation upon which all other patterns are based. It introduces a high-level view on an embedded system and refers to other object analysis patterns for refinement. 0 Fault Handler: Fault handng is crucial for embedded systems. In this pattern, a fault handler for an embedded system is specified. The fault handler collects fault messages from various sources and initiates corresponding recovery actions. 0 User Interface: User interaction is an important aspect of an embedded system. The system interacts with the user via so—called controls and indi- cators. Differing from sensors and actuators, interaction via controls and indicators is usually not as tightly constrained (e.g., timing constraints are less strict). The User Interface pattern describes how to specify an object model for a user interface that is extensible and reusable. o Watchdog: Embedded systems commonly have tight timing and oper- ational constraints. Monitoring these constraints and ensuring that they are not violated is the responsibility of a so-called watchdog. The watch- dog monitors a device or system conditions and initiates corrective ac- tion(s) if a violation is found. Figure 9.5: Current list of object analysis patterns for embedded systems [1] 172 systems. Furthermore, by adding specification-pattern-based [43] representations of properties to the Constraints field of the object analysis pattern template [53], de- velopers have some guidance as to what kinds of properties can be checked for a given system when a particular pattern is applied. The specification patterns [43] used in conjunction with object analysis patterns [1, 2, 3, 4] enable even novice developers to easily formulate claims to check the system for specific constraints. Then using IV’IcUmber’s formalization work [31, 33] and our model development and analysis pro- cess (Chapter 4), developers have a mechanism to rigorously check the requirements using simulation and model checking techniques [53, 41]. 9.2.1 Ob ject-Analysis-Pattern-Driven Modeling and Analy- sis Figure 9.6 illustrates how object analysis patterns [1, 2, 3, 4] and constraints [53] can be used to drive the iterative model development and analysis process described in Chapter 4. The user begins by selecting appropriate object analysis patterns based on the requirements of the system. Using the structural and behavioral diagrams in the object analysis patterns as a guide, the user constructs UML class and state diagrams in MINERVA’S graphical editors (Figure 9.6, part A). Hydra performs consistency checks (Figure 9.6, part B), and MINERVA visualizes structural consistency-checking results (dash-dotted arc in Figure 9.6, part F). (See Chapters 5 and 6 for details of these capabilities.) Hydra then generates formal models from textual representations of UML diagrams (Figure 9.6, part C); these formal models can be used to validate the UML diagrams through simulation using Spin (Figure 9.6, part D). Furthermore, constraints from the object analysis patterns can guide novices in constructing for- mal properties to check against their UML models. The user may instantiate (as LTL claims) properties from the Constraints field of those object analysis patterns used to guide the modeling of the system (Figure 9.6, part E). These LTL claims, defined 173 in terms of attributes, signals, and states of the UML model, can then be checked against the UML diagrams (Figure 9.6, part D) through model checking using Spin. Finally, MINERVA visualizes behavior simulation and counterexample traces (solid arc, Figure 9.6, part F) via state diagram animation, generation/ animation of collab— oration diagrams, and generation of sequence diagrams (Chapter 6), thus facilitating the debugging and refinement of the original UML diagrams. A complete example applying this process to an industrial case study can be found in [41] (where object analysis patterns were termed requirements patterns). o “ GRVA ‘ Prose requirements HIL Hydra V Object analysis , patterns User Mapping rules [constraints] for Promela commands _ Promela model r S in p ‘ Model ' checking Figure 9.6: Using object analysis patterns and constraints to drive the model devel- opment and analysis process LTL properties 174 9.3 Fault Handler Requirements Pattern Because this chapter focuses on patterns for handling fault-tolerance requirements, we next overview a particular requirements pattern, the Fault Handler requirements pattern [2, 3], that describes how to incorporate centralized fault handling into an embedded system (the complete Fault Handler requirements pattern is included in Appendix I). The pattern contains the UML class diagram template shown in Fig- ure 9.7 that suggests a structure or architecture for an embedded system with a centralized FaultHandler. A Watchdog, Examiner, or Monitor monitors a given Device and reports errors to the FaultHandler (the Device itself may also report errors to the FaultHandler). Based on the particular error message received, the FaultHandler performs an appropriate recovery action, such as sending a message to the Com- putingComponent (to initiate transitioning to a designated “safe” state, described in the next paragraph), the Userlnterface (to give warning feedback to the user), or a FailSafeDevice (to activate a redundant Device, such as a backup sensor, in case of hardware failure). The original Fault Handler requirements pattern as developed by Konrad and Cheng [2, 3, 4] also contains a UML state diagram template for the Computing- Component of an embedded system, as shown in Figure 9.8. The diagram template includes many different UML states, including either acceptable recovery states or “safe” states for the system (not all recovery states will be required by every sys- tem). Generally, recovery states (the states other than PowerOff and Hold shown as rounded rectangles in Figure 9.8) are intermediate states that eventually lead to either a system shutdown (i.e., the ComputingComponent transitions to state PowerOff) or a system reset (i.e., the ComputingComponent transitions to state Initialize). These intermediate states are described in more detail in the Fault Handler requirements pattern, included in Appendix I. The state PowerOf f is considered “safe” because the system is not executing and therefore cannot perform harmful actions. For our pur- 175 ComputingComponent controls sends values to FaultHandler Userlnterface A t° g ‘5 % 3 § 0..: o ' ° ' monitors 7 i ‘ backs up . 0..: Watchdog! °.- Device FailSafeDevlce Examiner 1 g t! 1 3‘ g 8 c O 5 0..: Monitor Figure 9.7: UML class diagram template from the original Fault Handler requirements pattern incorporating a FaultHandler into an embedded system 176 poses, the state Initialize is considered “safe” because (1) the system is believed to start in an acceptable or legal configuration (so that a system reset can successfully re-start the system in an acceptable state), and (2) during initialization, embedded systems generally perform built-in tests (BITS) or power-on self—tests (POSTS) and innnediately shut the system down if a problem is encountered. 9.3.1 UML Modeling and Semantics for the FaultHandler While the original Fault Handler requirements pattern [2, 3, 4] includes a state di- agram template for the Controller, it does not include a state diagram template for the FaultHandler. However, several of our case studies involving fault-handling (e. g., an Anti-Lock Braking System [53], a Diesel Filter System [41]) have modeled the be- havior of the FaultHandler in a way similar to that shown in Figure 9.9, that has now been codified as part of Detector-Corrector Pattern 3 (each detector is aggregated by a Watchdog, Examiner, Monitor, or Device as shown in Figure 9.10, a revised UML class diagram template also utilizing Detector-Corrector Pattern 3). The FaultHandler begins in state Monitoring. The reception of error messages is modeled using the signal StoreError(Error), where the FaultHandler attribute Error stores a numeric code indicating the specific error received (each modeled error for a given system uses its own unique code, often indicated in the requirements document for the system). When the FaultHandler receives an error message (due to a Watchdog, Examiner, Mon- itor, or Device detecting an error), it self—transitions to state Monitoring based on the error received. To ensure coverage for all modeled errors, there must be as many self—transitions for Monitoring as there are possible modeled errors. In Figure 9.9, these transitions are indicated by n transitions annotated with [Error == E-i] / ActionCorrector-i, 1 S i S n, where n is the number of possible modeled errors. The particular error code received (stored in the attribute Error) determines, via the guards, which one of these n self-transitions for state Monitoring is taken, thereby 177 \C \S 33056... A 832.5030 v 2.332333 J ‘ .5838 2833 GOHUIIdHldu-«QHH 1. \2 38.3. _ 855883. 2.338639% 2:39.933 — _ — 8823 05.2253 ‘3 Smugusam / \— _ m25:5...— xg 2E3 2056003“. 2. Spam-x — ‘ 8am engaged Lipase“... i.euw \ S Cueuuhdadaovuqfim \: 333358 _ \SCmuaatoouanm _—II \: Saga—5m \: 3:35- .2250 35.5.32. ._O_>fl£0m _NFEOZ \ 3 3033.324 \ HUI—VOOOOQI a Sauaufiuauafla 23583.. \3 30.3: 178 Figure 9.8: UML state diagram template for the ComputingComponent from the orig- inal Fault Handler requirements pattern, including “safe” states [2, 3, 4] determining which corresponding recovery action is performed. l “_SYSTEMCLASS_.OK StoreError(Error) [Error == E_n] / ActionCorrector_E_n StoreError(Error) [Error == E_1] / ActionCorrector_E_l V 1 Monitoring 2 A Figure 9.9: Sample UML state diagram template for a centralized FaultHandler (not included in the original Fault Handler requirements pattern) utilizing Detector- Corrector Pattern 3 The sample UML diagram templates for the FaultHandler shown in Figures 9.9 and 9.10 have the following characteristics. First, the FaultHandler receives error messages indicating particular problems from non-FaultHandler sources (e.g., a Watchdog, Ex- aminer, Monitor, or Device). Therefore, the FaultHandler itself is not involved in the actual detection of errors, but only the response to errors. Second, a Watchdog, Examiner, or Monitor typically monitors a single Device for problems. Thus, the er- rors detected and reported to the FaultHandler are localized to a particular Device or part of the system, rather than indicative of global error conditions (i.e., error conditions involving more than one component). Third, the original requirements patterns, including the Fault Handler requirements pattern, were developed with the idea of leveraging McUmber’s UML—to—Promela formalization [31, 33] in mind. The FaultHandler state diagram would therefore be translated to a Promela process and execute in the same manner as all other state diagrams in the UML model (F ig- ure 9.11). Spin interleaves all processes and has only weak fairness, so the Promela 179 monitors I l i Watchdog Examiner Monitor Device l f l l [ PredicateDetector PredicateDetector PredicateDetector PredicateDetector responds to responds to responds to responds to corrected by corrected by corrected by corrected by ActionCorrector ActionCorrector ActionCorrector ActionCorrector W {_J I Q sends errors to O FaultHandler reports to J sends values to UserInterface controls ComputingComponent Figure 9.10: Refined UML class diagram template for FaultHandler utilizing Detector- Corrector Pattern 3 180 process corresponding to the behavior (i.e., UML state diagram) of the FaultHandler might not execute immediately after an error is detected and reported. Class 1 process ® ------------ Class II process FaultHandler process Figure 9.11: Spin non-deterministically interleaves all processes (dashed lines), each representing the behavior of a UML class. 9.4 Refined UML Modeling, Semantics, and For- malization for the FaultHandler We refine modeling and semantics for the FaultHandler in two ways. First, we now allow the FaultHandler itself to perform global error detection, rather than only re- sponding to error messages received from external components due to the local error detection of those components. Global error detection enables detection of system conditions where, taken individually, local conditions do not indicate a problem, but when examined together (globally), they do indicate a problem. We enable the Fault- Handler to perform global error detection by allowing it access to all system variables. Because we allow the FaultHandler access to all system variables (i.e., all attributes in a UML model), global error conditions (e. g., the accelerator pedal is depressed to 181 a level indicating high demand, but the battery charge, while adequate for normal performance, is below the lowest acceptable level to provide power assist for a high- demand situation) can now be modeled by detectors aggregated by the FaultHandler. Second, because fault handling is a critical task, we may opt to increase its scheduling priority. The original semantics assumed by the Fault Handler requirements pattern executes all objects, including the FaultHandler, with the same priority, so that there may be a significant delay after an error has been detected before the FaultHandler performs a corresponding corrective action. Scheduling the FaultHandler to execute more often shortens the delay before corrective action is performed; however, doing so may incur a significant penalty in terms of increasing the size of the formal model’s state space. Global error detection. The refined UML class diagram template for the Fault- Handler utilizing Detector-Corrector Patterns 2 and 3 is shown in Figure 9.12. The FaultHandler itself now aggregates one or more pairs of PredicateDetector and Action- Corrector objects (i.e., utilizes Detector-Corrector Pattern 2). Thus, the FaultHandler itself can now perform error detection. The refined UML state diagram template for the FaultHandler utilizing Detector-Corrector Patterns 2 and 3 is shown in Figure 9.13. Similar to Figure 9.9 (page 179), the FaultHandler begins in state Monitoring. Using Detector-Corrector Pattern 3, we model the reception of error messages using the signal StoreError(Error), where the FaultHandler attribute Error stores a numeric code indicating the specific error received. When the FaultHandler receives an error message (due to a Watchdog, Examiner, Monitor, or Device detecting an error with a local detector, i.e., a detector examining only those attributes belonging to that component), it self-transitions to state Monitoring based on the error code received. In contrast to Figure 9.9, Figure 9.13 now also includes global detectors (detectors aggregated by the FaultHandler itself that may examine attributes from more than 182 one non-FaultHandler component) with corresponding correctors (Detector-Corrector Pattern 2). To enable the FaultHandler to perform global error detection, we revise our modeling and formalization frameworks to allow any Detector aggregated by the FaultHandler access to all system variables. In an actual embedded system, access to all system variables can be achieved through polling or shared memory. The existing UML—to—Promela formalization [31, 33] already declares all variables globally, so we assume shared memory in our model. monitors r"? r i Watchdog Examiner Monitor Device l l f l PredicateDetector PredicateDetector PredicateDetector PredicateDetector responds to responds to responds to responds to corrected by corrected by corrected by corrected by ActionCorrector ActionCorrector ActionCorrector ActionCorrector i i {2 sends errors to <> FaultHandler re orts to sends p l ? values to [ responds to UserInterface PredicateDetector ActionCorrector controls corrected by ComputingComponent Figure 9.12: Refined UML class diagram template for FaultHandler utilizing Detector- Corrector Patterns 2 and 3 Increased scheduling priority. As a further extension to modeling fault han- dling, we may adjust the underlying formalization semantics to increase the Fault— 183 “_SYSTEMCLASS_.OK [PredicateDetector_m] / ActionCorrector_m [PredicateDetector_l] / ActionCorrector_l StoreError(Error) [Error == E_n] / ActionCorrector_E_n StoreError(Error) [Error == E_l] / ActionCorrector_E_l k L Monitoring 1 + ” Figure 9.13: Refined UML state diagram template for FaultHandler utilizing Detector- Corrector Patterns 2 and 3 Handler’s scheduling priority. This approach may increase the size of the formal model’s state space, so additional abstractions may be needed. Spin has no built-in way to manage scheduling of processes, so we explicitly force the FaultHandler’s be- havior to be interleaved with the behavior of the rest of the system via a boolean fiag (Figure 9.14). We implement an increase in the scheduling priority of the Fault- Handler in Promela via a global boolean flag called global_UMLStep in the following manner. When global-UMLStep is true (i.e., equal to one), the rest of the system excluding the FaultHandler may take a step (take a UML transition). We model this constraint by adding, as a conjunct, the boolean condition (globaLUMLStep == 1) to all guards on non-initial transitions in all state diagrams in the UML model except for the _SYSTEMCLASS- (a modeling construct responsible for instantiating objects in the system), Environment (a modeling construct responsible for providing external stimulus to the system), and FaultHandler. Similarly, we add the entry action global_UMLStep := O to all states in all state diagrams in the UML model except for the _SYSTEMCLASS_, Environment, and FaultHandler. For convenience to the devel- 184 oper, these additions to the guards and entry actions can be performed automatically (and transparently) by either MINERVA (during generation of the intermediate textual representation), as shown in Figures 9.15 and 9.16, or by Hydra (during translation to Promela code, not shown). . . Class 1 process @ ------------ Class II prOCCSS FaultHandler process Figure 9.14: Forcing Spin to interleave the behavior of the FaultHandler with the be- havior of the rest of the system. Spin alternates between allowing the FaultHandler to take a step (solid line) and allowing one of many Promela processes, each representing the behavior of a UML class, to take a step (dashed lines). When globa1_UMLStep is false (i.e., equal to zero), the FaultHandler may take a step (i.e., a UML transition). We model this constraint by adding, as a conjunct, the boolean condition (global-UMLStep == 0) to all guards on non-initial transitions in the FaultHandler state diagram. We also add the action global_UMLStep := 1 to all non-initial transitions in the FaultHandler state diagram. For convenience to the developer, these additions to the guards and actions can be performed automatically (and transparently) by either MINERVA (during generation of the intermediate textual representation), as shown in Figures 9.17 and 9.18, or by Hydra (during translation to Promela code, not shown). 185 FaultHandler Scheduling Priority Rule 1: Description: Adds the conjunct (globaLUMLStep == 1) to guards on all non- initial transitions in all state diagrams in a UML model except for the state diagrams of the _SYSTEMCLASS_, Environment, and FaultHandler classes. Purpose: Ensures that non-FaultHandler, non-modeling-construct objects only exe- cute when the FaultHandler is not executing. Note: This addition can be performed transparently by MINERVA during generation of the intermediate textual representation as follows: ) let u be a UML model ) foreach class c E u ) if c ¢ {_SYSTEMCLASS_, Environment, FaultHandler} ) let sd be the state diagram of c ) foreach non-initial transition t E sd ) let g be the guard for t ) if g is empty then g +— global_UMLStep == ) ( ( ( ( ( ( ( ( elseg +— (( g) /\ (globaLUMLStep == 1)) 1 2 3 4 5 6 7 8 Figure 9.15: Rule for increasing the scheduling priority of the FaultHandler: non- FaultHandler components may only take a step when (globaLUMLStep == 1) 186 FaultHandler Scheduling Priority Rule 2: Description: Adds entry action global_UMLStep := O to all states in all state dia- grams in a UML model except for the state diagrams of the -SYSTEMCLASS-, Envi- ronment, and FaultHandler classes. Purpose: Ensures that after every step performed by non-FaultHandler, non— modeling—construct objects, the FaultHandler is enabled to execute (and non- FaultHandler, non-modeling-construct objects are disabled). Note: This addition can be performed transparently by MINERVA during generation of the intermediate textual representation as follows: ) let u be a UML model ) foreach class c E u ) if c g {_SYSTEMCLASS_, Environment, FaultHandler} ) let sd be the state diagram of c ) foreach state 3 6 sd ) let eas be the entry action sequence for s ) if eas is empty then eas <— global-UMLStep := O; ) else eas «— eas ; global-UMLStep := O (1 (2 (3 (4 (5 (6 (7 (8 Figure 9.16: Rule for increasing the scheduling priority of the FaultHandler: after every UML step, enable the FaultHandler to take a step 187 FaultHandler Scheduling Priority Rule 3: Description: Adds conjunct (global-UMLStep == 0) to guards on all non-initial transitions in the FaultHandler state diagram. Purpose: Ensures that the FaultHandler only executes when non-FaultHandler, non- modeling-construct objects are not executing. Note: This addition can be performed transparently by MINERVA during generation of the intermediate textual representation as follows: (1) let u be a UML model ( 2) foreach class c E u (3) if c E {FaultHandler} (4) let sd be the state diagram of c (5) foreach non-initial transition t E sd ( 6) let g be the guard for t (7) if g is empty then g <— global-UMLStep == (8) else 9 +— (( g ) /\ (global-UMLStep == 0)) Figure 9.1 7: Rule for increasing the scheduling priority of the FaultHandler: the F ault- Handler may only take a step when (globaLUMLStep == 0) 188 FaultHandler Scheduling Priority Rule 4: Description: Adds action global_UMLStep := 1 to all non—initial transitions in the FaultHandler state diagram. Purpose: Ensures that after every step performed by the FaultHandler, non- FaultHandler, non-modeling-construct objects are enabled to execute (and the Fault- Handler is disabled). Note: This addition can be performed transparently by MINERVA during generation of the intermediate textual representation as follows: (1) let u be a UML model ( 2) foreach class c 6 u (3) if c E {FaultHandler} ( 4) let sd be the state diagram of c ( 5) foreach non-initial transition t E sd ( 6) let as be the action sequence for t ( 7) if as is empty then as <— globa1_UMLStep := 1 (8) else as <— as ; globaLUMLStep := 1 Figure 9.18: Rule for increasing the scheduling priority of the FaultHandler: after every FaultHandler step, enable the rest of the model to take a step 189 9.5 Adaptive Cruise Control Example In this section, we apply our approach for modeling and analysis of fault handling to the Adaptive Cruise Control model from Chapter 7. Recall from Chapter 7, Property 6 (page 125), that if collision is imminent, yet the Adaptive Cruise Control-equipped car is still outside the safety zone, then the system will not begin disengaging until the Adaptive Cruise Control-equipped car has violated the safety zone. (Definitions of zones used by the Adaptive Cruise Control algorithm can be found in Appendix D.) This stipulation allows the driver time to change lanes without slowing down the car. We now examine the following related requirement: Requirement: If collision is imminent, yet the Adaptive Cruise Control- equipped car is still outside the safety zone, then an alarm sounds to warn the driver that action is required on the driver’s part (e.g., applying brakes, changing lanes) to avoid a collision. In the original UML model for Adaptive Cruise Control developed in Chapter 7, the concept of an alarm sounding was modeled by the Control periodically entering a state called sendwarn, as shown in the elided Control state diagram in Figure 9.19. The disadvantage of modeling any occurrence (such as an alarm sounding) as periodic entry to a particular non-final state 3 rather than as a particular boolean flag f becoming (and remaining) true is that any temporal logic claim involving <>(in(s)) ( eventually the model is in state 3) becomes violated as soon as the model leaves state .9. In the case of the Adaptive Cruise Control model from Chapter 7, the claim ( []( C (Control.xl < Control.xhit) & (Control.zl <= Control.xl) ) -> (8) <>( ( in(Control.sendwarn) 8t (Control.zl <= Control.xl) ) ) ) ) becomes violated as soon as the Control leaves the (non-final) state sendwarn. In order to address this shortcoming, we refine the way the concept of an alarm sounding is modeled in two ways. First, we model the alarm being triggered as a boolean attribute alarm in the Control class that is initially false (i.e., zero) and 190 ’ ---------- .- "‘ / \ / Calculate whether the Car 18 | Calculate I l closing in on the target or not; I xhit and : \Egpjhssalcueienezclesgeiav @5033”, l \ I I I close . [xhit<=xl]/ [x1 >=zl]/ m [x] < 21] / "Car.unset r 1 /-[xhit > x1] / / alloff T Safety zone . , violated. I Collrsron l imminent. _ _ 1 _ __ f \ Turn the t l Radar off : l and I I transition to I l state Idle. ,l \ _ ———’ Figure 9.19: Elided Control state diagram. Control periodically enters state sendwarn {shown as a bold rounded rectangle). Portions of the state diagram that have been abstracted for illustrative purposes are shown with dashed states and transitions ( dashed rounded rectangles and directed arcs, respectively). Notes indicating critical conditions in the model are shown as shadowed callout boxes. 191 becomes true the first time the Control state sendwarn is entered (i.e., we add an entry action to state sendwarn that sets the value of alarm to true (i.e., one)). However, the alarm being triggered does not necessarily mean that the alarm emits a sound. The Adaptive Cruise Control requirements stipulate that a microphone check to make sure that if the alarm is triggered, then a sound is actually emitted to warn the driver. Therefore, we additionally model the alarm emitting a sound as a boolean attribute sound in the Control class. The value of this attribute is initially true. These additions to the Control class and state diagrams are shown in Figures 9.20 and 9.21, respectively. In Figure 9.20, previously declared attributes have been elided, indicated with ellipses. In Figure 9.21, the state sendwarn is indicated in bold, while annotation boxes describe portions of the state diagram that have been elided. The Control enters the state sendwarn if the safety zone has not been violated, yet collision is imminent. Control bool alarm = 0 bool sound = 1 Figure 9.20: Refinements to Control class: Added boolean attributes alarm and sound. 9.5.1 Fault Handling in Adaptive Cruise Control We inject the following fault into the model: the alarm’s speaker fails during execution (i.e., after the cruise-control is in operation, as speaker failure prior to execution would be detected during initialization, not modeled here). As shown in Figure 9.22, we make a non-deterministic self-transition from the Control state warn to itself that sets the value of sound to false, indicating that the alarm fails to emit a sound (i.e., the alarm’s speaker has failed during execution). To handle this fault, we 192 I Calculate whether the Car is I Calculate ' : closing in on the target or not; I l xhit and l \ begin the calculation cycle again. l l xcoast. ,l “’F” _l ------------- . [xhit<=x1]/ [xl>=zl]/—‘ /[(xl < 21] / "Car. unset l sendwam l l ICntry/alarml :_ thlt > X1] / .lloff T Safety/ zone violated. : Collision I imminent. __ _ _1 _ _ \ Turn the 1 Radar off ' l and I transition to I s_tate Idle. Figure 9.21: Refinements to Control state diagram: Added entry action “alarm := 1” to state sendwam (both the action and the state are bold). Portions of the state diagram that have been abstracted for illustrative purposes are shown with dashed states and transitions (dashed rounded rectangles and directed arcs, respectively). Notes indicating critical conditions in the model are shown as shadowed callout boxes. 193 then introduce a FaultHandler into the model according to the Fault Handler object analysis pattern in the following manner. We detect the fault by testing the following condition: (Control_V.a1arm & !Control-V.sound). If the alarm is triggered, but the alarm does not emit a sound, then the driver is in potential danger and not aware of it. The best course of action is to disengage the cruise control, thus slowing the car by disengaging the throttle (the Adaptive Cruise Control does not have control of the brake). We therefore correct the problem with a recovery action that consists of sending a shutdown message to the Control. This condition and recovery action are modeled using Detector-Corrector Pattern 2 in the FaultHandler class and state diagrams as shown in Figures 9.23 and 9.24, respectively. We also refine the Control state diagram according to the Fault Handler object analysis pattern by encapsulating the previously modeled behavior in a composite state called Norma1_Behavior that has an outgoing transition to handle the new signal shutdown from the FaultHandler, with additional actions to turn off the remaining components in the system. We add the signal shutdown to the Control class diagram. These refinements are shown in Figures 9.25 and 9.26, respectively. From the refined UML diagrams, we generate the formal Promela model (without the optional increased scheduling priority). We then check the property ( [] ( ( Control.alarm 8: !Control . sound ) -> <>( send(Control . shutdown) ) ) ) (9) meaning that it is always the case that if the alarm is triggered and does not produce a sound, then eventually the system shuts down. The results are shown in Figure 9.27. 194 ’ ------------- .- “ / ----- \ I Calculate whether the Car IS \I l Calculate I : closing in on the target or not; I I xhit and : \Eginlhf gal-crila-tignfycfggfin/l l\ xcoast. , “I “r" I I []/sound :=0 l [xhit<=x1]/ warn [x1 >=zl]/ [x1 < 21] / "Car.unset [ sendwam . l[ ]/ entry/alarm :Dfixhit > x1]/ anoff T Safety zone violated. Collision imminent. I __ _ _1 _ _ / \ Turn the I Radar off : and I l I I l . . I trans1tion to | I Figure 9.22: Injecting a fault into the Adaptive Cruise Control model: Added non- deterministic self-transition with action “sound := O” to state warn in the Control state diagram to indicate that the alarm’s speaker fails (both the action and the transition are bold). Portions of the state diagram that have been abstracted for illustrative purposes are shown with dashed states and transitions (dashed rounded rectangles and directed arcs, respectively). Notes indicating critical conditions in the model are shown as shadowed callout boxes. 195 FaultHandler i l Alaran'ggeredNoSound : PredicateDetector detector : boolExprType = "((Control.alarm) & !(Control.sound))" l ShutdownACC : ActionCorrector corrector : actionSequpe = ""Control.shutdown" Figure 9.23: Adaptive Cruise Control FaultHandler class utilizing Detector-Corrector Pattern 2 l “_SYSTEMCLASS_.ready l \ I [AlarmTriggeredNoSound.detector] / ShutdownACC.corrector I Monitoring Figure 9.24: Adaptive Cruise Control FaultHandler state diagram utilizing Detector- Corrector Pattern 2 196 Control shutdown() : void Figure 9.25: Refinements to Control class to handle new signal shutdown from Fault- Handler Q " _SYSTEMCLASS_.ready l r Normal_Behavior R Control state diagram. C J shutdown [ l / "Car.unset "Radaroff I ( PowerOff) Figure 9.26: Refinements to Control state diagram to handle new signal shutdown from FaultHandler 197 (Spin Version 3.3.3 -- 21 July 1999) + Partial Order Reduction Full statespace search for: never-claim + assertion violations + (if within scope of claim) acceptance cycles - (not selected) invalid endstates (disabled by never-claim) State-vector 688 byte, depth reached 755, errors: 0 317 states, stored 19 states, matched 336 transitions (= stored+matched) 209 atomic steps hash conflicts: 0 (resolved) (max size 2‘18 states) 1.596 memory usage (Mbyte) Figure 9.27: Spin results for analyzing property 9 198 Chapter 10 Literature Review Developing specifications in any formal language, including Promela, manually has the potential to be an error—prone task. In an effort to leverage the benefits and address the shortcomings of both formal and semi-formal approaches to requirements analysis and design, many projects [22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35] have proposed techniques for associating formal semantics with semi—formal modeling notations, including UML [26, 28, 29, 30, 31, 32, 33, 35]. The work described in this dissertation leverages a particular approach to UML formalization [31, 33] but is not, itself, concerned with formalization approaches or techniques for automated generation of formal specifications. We refer the interested reader to [31] for a detailed discussion of these topics. While formalization of UML enables rigorous analysis of formal models derived from UML diagrams, formalization itself is not sufficient to broaden the community of (embedded systems) developers who can use formal methods to rigorously analyze re- quirements. To enable developers to model and analyze requirements in UML without having to know details of formal models requires a framework and process that takes advantage of a UML formalization yet insulates developers from the formal models produced by such a formalization. This research presents an approach to validating 199 embedded systems requirements modeled as both UML diagrams and temporal logic properties using formal verification (e. g., model checking) techniques. We describe a model development and analysis framework, complementary to a previously developed formalization framework [31, 33], that insulates the developer from formal models and outputs of tools. As shown in Figure 10.1, this framework includes a graphical edi— tor and visualization environment, and an analysis result processor (both shown as bold ovals). As shown in Figure 10.2, we instantiate the framework with tools (e. g., MINERVA, Hydra, and Spin) and describe an overall model development and analysis process that incorporates the following enabling techniques: model construction (Part A), automated generation of formal models (Part B), guidance for instantiation of formal properties (Part C), model analysis (Parts D and E), and visual interpretation of analysis results (Part F, bold arcs to the MINERVA process oval). This chapter overviews work related to these enabling techniques (with the excep- tion of automated generation of formal models; as noted previously, see [31] for details regarding this topic), as well as environments for embedded systems development, in- cluding formalized approaches and the leading commercial UML Computer-Aided Software Engineering (CASE) tools. 10.1 Guidance for Model Construction Our approach enables formal analysis of UML models of embedded systems require- ments. However, such models must first be constructed, and, as discussed in Chap- ter 3, shown to be well-formed, before they can be formally analyzed. Sections 10.1.1, 10.1.2, and 10.1.3 overview, respectively, how graphical editing environments, stereo- types, and patterns can provide user guidance for constructing well-formed UML- based requirements models for a given application domain, and how these techniques compare with our approach. 200 User input for graphical diagram(s) Graphical Editor & Visualization Environment Prose requirements Intermediate representation of diagram(s) Translator Mapping rules for formal language l l : commands l l Formal Language Analysis Tool(s) Analysis results (raw) Analysis results (human-readable) l. ______________ Analysis Result Processor Structural Analysis: Perform intra- and inter- diagram consistency checks prior to formal model generation. Formal Model Generation: Output graphical diagram(s) to intermediate representation, and generate formal model according to mapping rules. Formal Model Analysis (Behavioral Analysis): Perform syntax and semantics checks on formal model, and perform tool-specific analyses such as simulation or model checking. Analysis Result Processing: Convert raw analysis results into human-readable reports or visualization instructions. Figure 10.1: Model development and analysis framework 201 Prose requirements Hydra Mapping rules , for Promela commands _. Promela model Specification patterns l S in p * Model T checking Figure 10.2: Framework from Figure 10.1 instantiated with tools properties A 202 10.1.1 Graphical Editing Environments As discussed in Chapter 5, there are essentially three techniques that a graphical editing environment may use, in some combination, in order to ensure diagram well- formedness: prevention/containment, static consistency checking, and dynamic con- sistency checking. In this section we examine the first and third techniques; we consider static consistency checking as a structural analysis technique later in this chapter in Section 10.3.1. Prevention / Containment. In Chapter 5, Section 5.1.1, we discussed how a graph- ical editing environment, when augmented with knowledge of an ob ject-oriented nota- tion’s graphical syntax, can prevent certain types of graphical syntax violations from being drawn, or guide a user towards creating consistent diagrams. Our graphical ed- itor and visualization environment, MINERVA, is built atop Honeywell’s DOME (Do- main Model Editing) utility [87, 88]. DoME supports custom-built graphical editors, where the syntax of a diagram is described in terms of metamodels.1 The resulting graphical editors prevent developers (or automated diagram generation utilities such as our sequence— and collaboration—diagram visualizations) from constructing syntac— tically incorrect diagrams with respect to the constraints imposed by the underlying metamodels. As discussed in Chapter 5, generic drawing applications (e. 9., xi ig [76]) that have no knowledge of an object-oriented notation’s graphical syntax cannot impose any constraints on the graphical elements drawn. Such an application places the entire burden for well-formedness checking on a separate utility for static consistency check- ing. While UML does not require that a graphical editor supporting its notation use a metamodel-based approach for its own underlying implementation, it makes sense to leverage the UML’s metamodel. Therefore, we do not consider generic drawing 1Recall (Chapter 2) that a metamodel is a class diagram that describes the constructs of a modeling language and the relationships between the constructs. 203 applications further. It is possible, however, to provide a drawing application with text-based rules rather than a graphical metamodel depiction in order to constrain what can be drawn. For example, Method Workbench and MetaEdit+ [89] com— prise a suite of tools that provides a framework for defining domain-specific modeling languages and realizing customized domain-specific CASE tools. While the domain modeling language supports features similar to MINERVA’s underlying DoME meta- models (domain concepts and properties, visual symbols to represent them, and rules about how they are connected), the tools use text-based forms to define the concepts, properties, and rules rather than a graphical class diagram metamodel depiction. Dynamic Consistency Checking. Whether or not a graphical editing environ- ment has been augmented with knowledge of an object-oriented graphical notation’s syntax, the environment must still perform some consistency checking (i.e., metamod- els or rules cannot prevent or contain every error). This task can be performed either statically (as a separate step after the user reaches a stopping point in the drawing of a diagram), or dynamically (i.e., the environment constantly monitors the status of the diagram-in-progress, alerting the user to possible errors). As described in Chap- ter 5, Sections 5.1.2 and 5.1.3, MINERVA and Hydra use static consistency checking to detect diagram anomalies not inherently prevented by MINERVA’s metamodel-based editors; in Section 10.3.1 we examine static consistency checking in more detail. In contrast, here we consider how dynamic consistency checking can also be incorpo- rated into a graphical editing environment in order to guide a developer in producing well—formed UML models. ArgoUML [90], for example, is a graphical editing environ- ment for UML diagrams that provides interactive guidance during model construction via analysis agents, called design critics, based on “best practices” for software de— sign. Design critics continually monitor a UML model-in-progress, offering advice and warnings in the form of dynamically updated to—do lists and highlighted diagram 204 elements. While this approach is based on cognitive psychology principles that enable the user to continually reflect upon and improve a design—in-progress, there may be an implicit cost in terms of negative user attitude incurred by the “constant critique” approach. Additionally, the critics are implemented as separate threads running in parallel, so there is a much higher computational cost than for static consistency checking. Comparison with Our Approach. We find that using MINERVA’s underlying metamodels and structural guidance within its graphical user interface to prevent and / or contain graphical and textual errors as much as possible, and then using static consistency checking to detect definition/ usage and other discrepancies, including graphical syntax anomalies such as a missing start state, effectively distributes the responsibilities for consistency checking between the graphical editing environment and other utilities without unduly constraining the user during model development. 10. 1.2 Stereotypes UML was developed to be a general-purpose software modeling language. However, despite its attempt to be all things to all people, developers may still need modeling elements more specific to a given application domain than those already present in the UML. Stereotypes [16, 17, 18] in UML address this problem, allowing developers to extend the UML with new modeling elements specific to a given application domain. This approach has been used generally for modeling product lines [91] and system families [92], as well as more specifically for modeling middleware [93], fault-tolerant real-time systems [94] and embedded systems [95, 96], to give some examples. Comparison with Our Approach. McUmber’s formalization framework [31, 33], leveraged by our model development and analysis framework, uses only the model- ing elements already present in the UML without extending it, in order to make the 205 approach available to any general-purpose UML modeling tool, and potentially appli- cable to other application domains besides embedded systems. However, in the past several years, stereotypes (an extension mechanism), and more recently, profiles2 [97] (in part, a constraining mechanism) have become more prevalent for domain-specific modeling (e. g., real-time modeling [98]; data modeling [99]; web modeling [100]; busi— ness modeling [101]; schedulability, performance, and time modeling [102]; CORBA modeling [103]). Stereotypes allow developers to model their systems using model- ing elements specific to their application domain, i.e., elements that model familiar objects and concepts. Profiles combine this approach with the technique of limiting the developers’ modeling “palette” to only the necessary elements; for example, the approach discussed in this dissertation uses only the UML class and state diagrams for modeling embedded systems. An UML-based approach that extends UML with stereotypes that represent familiar objects and concepts within a specific applica- tion domain, yet limits the available modeling elements to only the ones necessary for modeling that domain, can guide developers unfamiliar with UML in both con- structing models that have domain-specific meaning, and avoiding constructing extra diagrams or diagram elements that have not been found generally useful for modeling that domain. If we chose to incorporate stereotypes into our approach, possible candidates would be the special modeling constructs _SYSTEMCLASS_ and Environment. These con- structs are really specialized classes used for modeling purposes, so stereotypes rep- resenting them could be reused for other application domains. Other, embedded- system-domain-specific, candidates for stereotypes would be sensors and actuators. However, because these concepts are domain-specific, adding such stereotypes would make the approach more explicitly tied to the embedded—systems domain, and there- fore less generally applicable. 2A profile is a subset of UML tailored to a specific application domain. 206 10. 1.3 Patterns Patterns are a third way to provide user guidance for constructing UML-based mod- els for a given development phase and/ or for a given application domain. Patterns supercede well-formedness constraints and stereotypes by offering diagram templates that express relationships between diagram elements specific to a given problem or application domain (e. g., the Visitor design pattern [83] enables the definition of new operations on an object without changing the object; the Watchdog real—time safety and reliability design pattern [104] enables time—based detection of deadlock in real- time systems). Patterns largely entered the software engineering scene with the advent of Gamma et al.’s book Design Patterns [83] that provided a catalog of creational, structural, and behavioral patterns to guide construction of object-oriented models during the design phase of development. Patterns for other development phases (e. g., analysis patterns [105], architectural patterns [106], etc.) and specific application do- mains (e.g., database access patterns [107], fault-tolerant telecommunication system patterns [108], design patterns tailored to distributed real-time embedded systems (DREs) [109, 110, 111, 112], design patterns for avionics control systems [113], real— time design patterns [104, 114], security patterns [115], etc.) soon followed. Here, we overview design patterns and analysis patterns for the embedded systems domain, as well as fault-tolerance patterns. Design Patterns and Analysis Patterns. Currently much of the embedded sys- tems industry uses ad hoc development approaches [37] that emphasize design and coding over analysis [116]. The large number of design patterns [83], especially those tailored to real-time systems [104, 114] and distributed real-time embedded systems (DREs) [109, 110, 111], is further evidence of this focus. Despite its importance, the analysis phase is often neglected in current embedded systems development practice, often causing conceptual errors to be propagated to design and coding [36]. 207 To address this problem, Konrad et al. propose requirements patterns [2, 3, 4] (now termed object analysis patterns [1]) for use in the analysis phase of embedded systems development to guide the construction of a conceptual model of a system. Analysis patterns are not new per se (e.g., [36, 105, 117, 118]); for example, Fowler [105] identified several patterns that might be used during the analysis phase to repre- sent conceptual models of business processes, such as abstractions from accounting, trading, and organizational relationships. While Fowler’s analysis patterns may be relevant to only one application domain, or may span several domains, Konrad et al.’s object analysis patterns focus explicitly on software development for the embed- ded systems domain. Fowler also uses an informal description style for his patterns, while Konrad et al. use a template similar to the one used by Gamma et al. for their design patterns [83], with some modifications. (To distinguish the contents and objectives of their work from Fowler’s, and to leverage Douglass’s ROPES [37] de- velopment process, Konrad et al. use the term object analysis patterns instead of analysis patterns.) Object analysis patterns not only guide developers in constructing UML-based conceptual models of requirements, but, unlike the other pattern approaches previ- ously mentioned, also provide property templates so that developers are able to val- idate their conceptual models, prior to design, by leveraging McUmber’s previously developed UML formalization framework [31, 33]. Fault-Tolerance Patterns. Fault-tolerance, the ability of a system to continue to execute correctly in the presence of a finite number of hardware and software faults, is a non-functional property potentially desired by many high-assurance applications, including fault-tolerant (individual or distributed) embedded systems. For example, several of Konrad et al.’s previously identified requirements patterns for individual embedded systems [2, 3, 4], namely the Actuator-Sensor, Watchdog, Fault Handler, 208 Communication, and Actuation-Monitor patterns, offer informal guidelines for mod— eling fault-tolerance under different contexts. Some of these, such as the Actuator- Sensor, Communication, and Actuation—Monitor patterns, suggest introducing fault- tolerance at the architectural level via the common technique of redundancy (e.g., if a primary sensor fails, then a backup sensor takes over). Indeed, design patterns for fault-tolerance in non-distributed systems exist that make use of hardware and/ or software redundancy. For example, Daniels et al. [119] present a general design pattern for software fault—tolerance utilizing redundant vot- ing strategies to minimize the potential for common-cause software faults. Ferreira and Rubira [120] present a system of design patterns to implement fault-tolerance that utilize replication, diversity, and exception-handling redundancy strategies for hardware, software, and environmental faults, respectively. Comparison with Our Approach. As discussed in Chapter 9, requirements pat- terns [2, 3, 4] (now termed object analysis patterns [1]) can be used to drive our model development and analysis process introduced in Chapter 4. In comparison to our work, none of the other aforementioned pattern approaches offers a combination of patterns to guide construction of conceptual models, templates for the formal spec- ification of critical properties, and a formalization framework tailored to the software analysis process of embedded systems development. With regards to fault-tolerance patterns, while redundancy can reduce (but not eliminate) the risk of system failure due to random faults in hardware or common- cause software faults [37], it does not address detecting or handling faults due to inappropriate, missing, ill-timed, or out-of—sequence actions, or dangerous and/or illegal system conditions. The fault—handling patterns described in Chapter 9, based on the concepts of detectors and correctors [57], enables developers to model fault handling requirements and analyze them using specification-pattern-based constraints 209 related to the occurrence and ordering of actions such as message reception. 10.2 Guidance for Instantiating Formal Properties Using our approach, developers can check requirements-based properties against the formal model derived from UML diagrams. Developers instantiate properties in terms of UML elements, such as attributes, states, and messages. Our approach recommends the use of specification patterns [43], temporal logic templates for specifying commonly occurring properties, to guide the formation and instantiation of requirements-based properties in LTL to check against the derived formal Promela model using Spin. Requirements patterns [2, 3, 4], now termed object analysis patterns [1], take this idea one step further. They contain specification-pattern-based constraints [53] that can be checked against UML models that have been constructed using the diagram templates in the object analysis patterns. Thus, the object analysis patterns provide context for the constraints, so that developers not only know how but also when to instantiate and check a given property. Comparison with Our Approach. Chapter 2, Section 2.2.4, briefly overviews specification patterns, and Chapter 4 discusses their role in our approach. As dis- cussed in Chapter 9, object analysis patterns [1] can be used to drive our model development and analysis process introduced in Chapter 4. Both specification pat- terns and object analysis patterns provide guidance to developers for instantiating formal properties; however, without a framework and process to leverage this capa- bility, their utility is limited. Our model development and analysis framework and process leverage these patterns, providing developers with a mechanism to construct diagrams against which to check instantiated properties in order to validate require- ments. 210 I—‘v 10.3 Model Analysis As discussed in Chapter 5, we divide analysis into two phases, structural analysis and behavioral analysis. Structural analyses (i.e., consistency checks) are performed on UML models (i.e., diagrams), while behavioral analyses (i.e., simulation and model checking with Spin) are performed on formal (i.e., Promela) models. We overview work related to these tasks in Sections 10.3.1 and 10.3.2, respectively. 10.3.1 Diagram Consistency Checking The Object Management Group (OMG) developed well-formedness rules for UML that CASE tools for UML (e.g., IBM’s Rational Rose) should support. We have already discussed in Chapter 5, Section 5.1.1, and this chapter, Section 10.1.1, how some such rules can be enforced a priori by a metamodel-based or otherwise rule- enhanced graphical editing environment; however, consistency checking is still re- quired for those rules that a graphical editing environment cannot enforce a priori. Existing CASE tools for UML support the well-formedness rules in a variety of ways (e.g., some combination of metamodel- or rule-based constraints, and static or dy- namic consistency checking); here we overview one general-purpose approach to static consistency checking, xlinkit [21], that could be utilized by any UML CASE tool that supports XML3 [121] and the XMI4 format. (ArgoUML’s design critics [90], discussed in Section 10.1.1, are an example of dynamic consistency checking.) The xlinkit [21] tool offers a framework for rule-based detection of inconsistencies between distributed XML [121] documents. In particular, static consistency checking based on the OMG well-formedness rules for UML can be performed on UML diagrams in ’XMI format. The tool automatically generates hyperlinks, where an inconsistent link relates ele- ments that violate consistency rules. 3Extensible Markup Language 4XML Metadata Interchange 211 Comparison with Our Approach. The application of the xlinkit framework to static consistency checking of UML diagrams is complementary to our approach and quite powerful. Its ability to check distributed documents is especially pertinent to industry, where projects may contain thousands of diagrams in documents spread across several networks or even continents. However, xlinkit is targeted entirely to- wards consistency management rather than dynamic property verification. 10.3.2 Behavioral Analysis of UML Diagrams with Spin The model checker Spin [69] was developed in the 1980’s at Bell Labs specifically for the verification of distributed software systems. While Spin originated in the telecommunications industry, it has gained increasing use in other industrial domains involving distributed [122] and embedded systems, such as flight systems [123] and railway systems [124]. Its non-deterministic input language, Promela, is loosely based on Dijkstra’s guarded command language [125] and Hoare’s CSP (Communicating Sequential Processes) [126]. Our approach uses the Spin model checker to validate (embedded systems) re- quirements expressed as LTL properties and UML diagrams. Therefore, we limit our discussion here to two UML—based graphical front-ends to Spin: vUML [127] and the Visual Interface for Promela (VIP) tool [128]. The vUML tool translates UML state diagrams to Promela and displays counterexamples as UML sequence diagrams. VIP supports a visual extension to Promela, called v-Promela, that ex- tends the Promela language with graphical notations and object—oriented concepts. VIP translates UML-style collaboration diagrams (termed structure diagrams in v- Promela) and state diagrams to Promela, using many Promela-specific notations in the UML diagrams. 212 Comparison with Our Approach. McUmber’s formalization framework [31, 33], leveraged by our approach, was designed to be as target-language independent as possible at the graphical modeling level. It includes a generic syntax for commonly occurring concepts such as boolean expressions, variable assignments, and message sends that are transparently translated to formal language syntax (e.g., Promela) dur- ing formal specification generation; developers do not need to know formal language syntax. Additionally, the formalization framework may be extended with formaliza- tion rules for other target languages (e. g., VHDL [30]), so it, and thus our approach, is not specifically tied to Promela and Spin. Finally, Hydra generates Promela from both the class and state diagrams, rather than state diagrams only, while MINERVA animates the original UML state diagrams, as well as generating UML sequence and collaboration diagrams, based on the behavioral analysis results from simulation and model checking using Spin. 10.4 Visual Interpretation of Analysis Results We divide analysis into structural and behavioral phases, with corresponding visual- ization techniques, so we briefly overview approaches to both types of visualizations here. Regarding structural visualization techniques, static consistency checking tools generally highlight questionable diagrams and/ or diagram elements (e. g., xlinkit [21] highlights questionable relationships between such items), while dynamic consistency checking tools such as ArgoUML [90] highlight questionable diagrams and / or diagram elements and offer textual messages to the user (e. 9., additional warnings, error mes- sages, or advice). Regarding behavioral visualization techniques, commercial UML CASE tools for embedded systems development (e. g., [19, 20, 129, 130]) overwhelm- ingly visualize simulation traces with state diagram animation and sequence diagram generation and / or animation. 213 Comparison with Our Approach. Chapter 6 discusses our visualization tech- niques for displaying results of both structural and behavioral analyses to the user. MINERVA’s structural visualizations include textual messages and highlighting ques- tionable diagram elements. MINERVA’s behavioral visualizations include state dia- gram animation, sequence diagram generation, and collaboration diagram generation and animation. In addition to displaying message ordering, we include the capability to display attribute values and the current state of each object during collaboration diagram animation, thus augmenting the amount and type of information usually displayed with either a state diagram (current state) or a sequence diagram (message ordering). Additionally, our approach incorporates both structural and behavioral analyses rather than only one or the other, so we likewise incorporate both structural and behavioral visualizations into one environment. 10.5 Development Environments for Embedded Systems This research presents an approach to validating embedded systems requirements modeled as both UML diagrams and linear time temporal logic (LTL) properties using formal verification ( e. g., model checking) techniques. We developed a model development and analysis framework (Chapter 4) that leverages, integrates, and en- capsulates a previously developed formalization framework for object-oriented nota- tions [31, 33], including feedback to diagrams from formal analysis tools in order to insulate users from the outputs of such tools. We also developed an iterative and incremental model development and analysis process (Chapter 4) that comprises steps for (1) model construction, (2) structural and behavioral analyses, and (3) re- finements based on feedback from both types of analyses. While previous sections explored work related to the enabling techniques for these steps, this section com— 214 pares our approach with leading environments for embedded systems development, including formal and commercial approaches. Specifically, we overview the Omega project [131], the Software Cost Reduction (SCR) toolset SCR* [132], the NIMBUS environment [133] that leverages RSML [134] specifications, and the four major com- mercial UML CASE tool offerings for embedded systems development according to current market research [135]: ARTiSAN’s Real-time Studio [129], IBM Rational’s Rose RealTime [19], I-Logix’s Rhapsody [20], and Telelogic’s TAU Generation2 [130]. The main difference between our approach and the commercial environments is that they rely on validation and testing rather than verification techniques; therefore, we do not include a separate comparison section for each but highlight salient differences within the overview of each environment. 10.5.1 Omega Project The EU-IST Omega project [131] (Correct Development of Real-Time Embedded sys- tems) selects a subset of UML, including class and state diagrams, applicable to the embedded systems domain and extends this subset by leveraging the Schedulability, Performance and Time profile [102] to create an Omega kernel model, or interme- diate representation in XMI format [121], used as the basis for a common input to different formal analysis tools. The intermediate representation has a fixed formal semantics, and connects commercial UML CASE tools such as Rhapsody [20] and TAU [130] with formal tools such as model checkers or interactive theorem provers. Requirements may be expressed via Live Sequence Charts (LSCs) [136], a subset of OCL [137], or special state machines stereotyped as observers. Omega supports inter- active simulation of LSCs, while error traces from formal analysis tools are provided to the user as scenarios. 215 Comparison with Our Approach. Our approach leverages McUmber’s formal- ization framework [31, 33], that maps a unified metamodel of a subset of UML into the metamodel of the syntax of a formal target language. The source UML meta- model remains fixed, while the metamodels for different target languages will vary as the syntax of each target language varies. The Omega project translates UML models into an intermediate representation, the Omega kernel model, that has a fixed seman— tics. This model is used as the basis for further translation to the input format of formal analysis tools. The Omega project formalizes a few additional UML concepts not addressed in McUmbers’s formalization embodied by Hydra: Hydra supports asynchronous signal—based communications only, whereas Omega also supports syn- chronous operation calls; in Hydra, all classes have associated state diagrams, whereas Omega makes a distinction between reactive and non-reactive classes (only reactive classes have associated state diagrams); in Hydra, each class has its own thread of control and event queue, whereas in Omega, only active classes do so. Addition- ally, the Omega project includes support for timing, whereas McUmber’s original formalization framework did not; current work has focused on extending McUmber’s formalization with timing [54]. While Omega provides error traces to the user in the form of scenarios (it is unclear whether this terminology refers to LSCs, sequence diagrams, or use case diagrams—the most likely case is sequence diagrams), more elaborate feedback mechanisms are outside of the scope of the project. As we have learned from case studies (e. g., [1, 41]), sequence diagrams display the sequence of events leading up to an error, but do not always provide enough information to deter- mine why the error occurred. Therefore, in addition to sequence diagram generation, our approach enables state diagram animation and collaboration diagram generation and animation in order to provide the user with additional information. 216 10.5.2 SCR* SCR* [132] is an integrated tool suite supporting the Software Cost Reduction (SCR) method. SCR uses a tabular notation to capture behavioral information about re- lations between monitored and controlled variables. The tool suite SCR* offers a simulator and verification capabilities through the use of model checkers and theorem provers. Recently, Gargantini and Riccobene developed an approach to model-driven animation of SCR specifications [138]. This approach derives animation goals from either predicates over states or temporal logic formulas. Predicates or formulas are specified by the user based on SCR tables, and are used as input to model checkers integrated into SCR* (e. 9., Spin [69] or SMV [75]). A detected counterexample then becomes an animation scenario animated via graphical user interface (GUI) wid- gets that may mimic actual control panels, or otherwise display information about monitored and controlled variables. Comparison with Our Approach. Although its tabular notation is much differ- ent from the UML diagrammatic notation used in our approach and currently being adopted by industry, SCR has been successfully applied to large-scale critical systems (e.g., avionics systems [139], weapons control systems [140], etc). When combined with Gargantini and Riccobene’s animation approach [138], formal analysis results, can be displayed in formats more accessible to users, such as control panels that mimic the actual deployed system. In this way, SCR* meets our goal of insulating developers from formal analysis tools, although the analysis results are not displayed in terms of the original model (in SCR*, tables; in our approach, UML diagrams). Because we also utilize counterexamples to drive our animations, we could extend our visualization techniques to include animating GUI widgets like Gargantini and Riccobene in order to present information to users in terms of the context of the deployed system. 217 10.5.3 NIMBUS The N IMBUS environment [133] is a framework for specification-based prototyping of embedded systems. The environment enables simulation of RSML (Require- ments State Machine Language) [134] specifications of embedded systems compo- nents. RSML, based on Harel’s Statecharts [62], was originally developed as a spec- ification language for embedded systems requirements. RSML specifications can be analyzed for completeness, consistency, and adherence to safety and liveness proper- ties. The NIMBUS environment provides for iterative refinement of an RSML specifi- cation to the point of executing it directly within the context of actual hardware, or “hardware-in-the-loop” simulation. Comparison with Our Approach. The N IMBUS environment [133] directly in- corporates RSML specifications, whereas our approach leverages McUmber’s general formalization framework [31, 33] that enables flexibility for targeting different formal languages and analysis tools. It is not clear from the description of the NIMBUS envi- ronment whether guidance is provided to developers for creating RSML specifications or formulating properties to check against them; however, like SCR [132], the speci- fications utilize a tabular notation. A software emulation of the environment drives simulation, and information about controlled variables is collected in text files for later examination with spreadsheets rather than being presented in terms of RSML. 10.5.4 ARTiSAN’s Real-time Studio ARTiSAN ’s Real—time Studio [129], a suite of tools for software modeling and compo- nent based development, enables developers to model system architecture and func- tional requirements. It supports both stereotypes and profiles, including real-time extensions to UML. Executable code is automatically generated from UML state diagrams, including test harnesses. Animation of sequence and state diagrams en- 218 able developers to validate system behavior via simulation. There are no underlying formal semantics; this tool suite relies on validation and testing rather than formal verification. 10.5.5 IBM Rational’s Rose RealTime Rational Rose [19], a general-purpose UML modeling tool, is part of a family of integrated products that support the analysis, design, implementation, and testing phases of software development. It offers a “modelcheck” utility that detects diagram construction errors such as unconnected associations or transitions, which we avoid inherently with MINERVA’s metamodel-based graphical editors. On the other hand, the Rational Rose RealTime suite, aimed at embedded systems software development, has been optimized to model concurrent, event-driven, reactive, and state-based sys- tems. Validation is performed by generating executable code from UML models, while the visual debugger shows message traces and state changes on the UML models at runtime. Nevertheless, both families of products, oriented towards code generation, rely on validation and testing rather than formal verification. 10.5.6 I-Logix’s Rhapsody I-logix’s Rhapsody [20] family of products offers a UML-driven approach to analysis, design, testing and implementation of embedded systems: Use cases and sequence di- agrams capture requirements; object diagrams depict system architecture; statecharts and activity diagrams model component behavior; and component diagrams describe run-time artifacts. Design-level debugging features include highlighting states in stat- echarts, displaying message traces in sequence diagrams, and monitoring attribute value changes. While the underlying semantics of the executable models developed with these products is based on Harel’s Statecharts [62], McUmber’s formalization framework [31, 33] that underlies our approach enables support for different seman- 219 tics and integration with various formal verification tools. 10.5.7 Telelogic’s TAU Generation2 Telelogic’s TAU Generation2 tool suite [130] consists of four products: TAU/ Architect, TAU/ Developer, TAU/ Tester, and TAU/Logiscope. These tools are used for systems architecture and design, model-driven software development, systems and integration testing, and software quality assurance and metrics, respec- tively. TAU / Architect and TAU / Developer are the most closely related to our work. TAU / Architect enables developers to create UML-based structural (e.g., component diagrams) and behavioral models (e. g., state diagrams) and use simulation to validate them. It allows user-defined symbols for domain-specific modeling (i.e., stereotypes). TAU / Developer compiles executable models from the diagrams and includes a model debugger that includes visualizing execution traces with on-the—fly creation of se- quence diagrams and animation of the model’s state diagrams. Again, this tool suite relies on validation and testing rather than formal verification. 220 Chapter 11 Conclusions and Future Investigations While requirements errors can be costly for software systems in general [9], they can be especially costly for high-assurance or safety-critical embedded systems where failure can have dire consequences. Therefore, methods for modeling and rigorously analyzing embedded systems requirements are needed. However, the ad hoc devel- opment approaches currently used in embedded systems lack systematic methods for both modeling and analyzing requirements [37, 38]. Although the embedded systems community has expressed interest in exploring how object-oriented modeling, specifically the UML, can be used for embedded sys— tems development [37, 38, 39], UML lacks a formal semantics, thus precluding rigorous analysis of requirements expressed as UML models. While formalization of UML en- ables rigorous analysis of formal models derived from UML diagrams, formalization itself is not sufficient to broaden the community of embedded systems developers who can use formal methods to rigorously analyze requirements. To enable developers to model and analyze requirements in UML without having to know details of formal models requires a framework and process that takes advantage of a UML formalization 221 yet insulates developers from the formal models produced by such a formalization. This research presents an approach to validating embedded systems requirements modeled as both UML diagrams and temporal logic properties using formal veri- fication (e.g., model checking) techniques. We describe a model development and analysis framework, complementary to a previously developed formalization frame- work [31, 33], that insulates the developer from formal models and outputs of tools, and an overall model development and analysis process. We have validated this work by applying the approach to several case studies from industrial collaborators: e an Adaptive Cruise Control system [40, 77] (also described in Chapter 7) that uses radar to avoid collisions, e an Anti-Lock Braking System [53, 86] with redundant brake sensors, 0 a self-cleaning Diesel Filter System [41, 42, 84] that removes soot from diesel truck exhaust, and most recently 0 an Electronically Controlled Steering system [54, 55, 141] that provides variable- assistance power steering. Each case study uses the integrated model development/ analysis and formalization frameworks from Chapter 4 instantiated with tools (e. g., MINERVA [40, 47, 49, 50, 51, 52, 56], Hydra [31, 33, 48], and Spin [69]) as described in the process diagram in Fig- ure 4.3, page 55, and demonstrated in the remainder of the dissertation. Additionally, the latter three studies leverage object analysis patterns [4] as described in Chapter 9, Section 9.2, while the Electronically Controlled Steering system uses an extension of McUmber’s formalization framework with timing information [54, 55]. These case studies demonstrate that our framework and process enables embedded systems de- velopers to model and analyze their requirements in UML with formal-verification 222 (e. g., model checking) techniques while being insulated from formal models and out— puts of tools. 11.1 Summary of Contributions In summary, this research makes several contributions [1, 40, 41, 42, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56]: o Bifurcated approach to analysis [40, 47, 51]. Preliminary investiga- tions [44, 45, 46] (Chapter 3) indicated that formal analysis tools are not well- suited to detecting structural problems within the formal models generated from diagrams; that is, diagram well-formedness should be checked prior to for- mal model generation. Therefore, we describe and demonstrate a bifurcated approach to analysis (Chapter 5) that incorporates both structural (diagram level) and behavioral (formal model level) analyses. Impact. While formalization of object-oriented notations combined with au- tomated generation of formal specifications enables rigorous analysis of diagrams (via the formal specifications), such formalizations make implicit assumptions about the well-formedness of diagrams. Ill-formed diagrams may result in de- generate formal models, but in ways that cannot be detected by the formal analysis tools (Chapter 3 presented several examples). Therefore, an approach to formalizing ob ject-oriented notations intended for use by typical software de- velopers must include diagram consistency-checking (structural analysis) prior to formal model generation and behavioral analysis. 0 Visualization of analysis results to guide diagram refinements [40, 41, 47 , 50]. We developed visualization techniques for results of both structural analyses of diagrams and behavioral analyses of automatically generated formal 223 models. Visualizations (Chapter 6) include highlighting portions of diagrams, animating diagrams, and generating new diagrams. Impact. As discussed in Chapter 6, analysis results from formal language analysis tools are often cryptic, and are expressed in terms of the formal model rather than the original diagrams. Therefore, an approach to rigorous analysis of ob ject-oriented diagrams incorporating formal language analysis tools intended for typical software developers must include a mechanism for interpreting formal analysis results in familiar terms; we have chosen to interpret and visualize results in terms of the original UML diagrams or complementary ones in order to facilitate model refinement and understanding. Framework and process for development and analysis of (formalized) UML models [40, 41, 49, 56]. We developed a model development and anal- ysis framework (Chapter 4) that leverages, integrates, and encapsulates a previ- ously developed formalization framework for ob ject—oriented notations [31, 33], including feedback to diagrams from formal analysis tools in order to insulate users from the outputs of such tools. We also developed an iterative and in- cremental model development and analysis process (Chapter 4) that comprises steps for (1) model construction, (2) structural analyses, (3) behavioral analy- ses, and (4) refinements based on feedback from both types of analyses. Impact. Automated tools are necessary to broaden the community of users who can take advantage of the benefits of formal methods. The model develop- ment and analysis framework (embodied by MINERVA) described in Chapter 4 encapsulates an existing formalization framework (embodied by Hydra), thus providing a graphical diagram editing and visualization environment as both a front-end for the formalization framework and a back—end for formal analysis 224 tools. While analysis and visualization techniques, and a framework to support them, are important, they have greater impact and utility when incorporated into a systematic process that guides typical software developers in modeling and analyzing their requirements. Chapter 4 describes our process, and the industrial case study presented in Chapter 7 illustrates its application to a real- world embedded system. Typical software developers thus have a systematic process and tools with which to model their requirements and view analysis results in UML. Structural and behavioral patterns for modeling fault handling. High- assurance systems must often remain operational even in the presence of faults. We developed structural and behavioral patterns for modeling the fault- tolerance concepts of detectors and correctors [57] in UML (Chapter 9) to pro- vide guidance for modeling and analyzing fault handling requirements. Impact. In Chapter 9, we extended our framework and process to incorporate requirements patterns [2, 3, 4] (now termed object analysis patterns [1]) that use templates for (UML) diagrams and (temporal logic) system properties to guide developers in creating UML models and instantiating properties to check against them. We used our patterns for detectors and correctors to refine Konrad et al.’s original Fault Handler requirements pattern [2, 3, 4], and applied the refined requirements pattern to the Adaptive Cruise Control example from Chapter 7. Patterns for specific application domains, such as embedded systems, provide guidance for typical software developers who may not be familiar with UML, formal methods, or a given application domain, in constructing UML models of their requirements and in instantiating temporal logic properties to check against their models. 225 Collective impact. An overarching objective of this research was to facilitate tech- nology transfer of rigorous software engineering techniques to typical software devel- opers, especially in the embedded systems domain. As the complexity and critical na- ture of embedded systems increase, developers can no longer rely on ad hoc methods. Effective analysis techniques are needed to minimize the number of errors introduced during the early stages of development, and to assist in detecting the causes of such errors. Our model development and analysis framework and process, integrated with McUmber’s formalization framework [31, 33], enable rigorous analysis of UML-based requirements using consistency—checking, simulation, and model checking techniques, all combined with visualizations of analysis results. Therefore, the collective contri- bution of this work enables developers from the broad UML user community to make use of formal-verification tools to support model validation while being insulated from the formal models used by these tools. 11.2 Future Investigations Several investigations complementary to the research presented in this dissertation may be pursued in future work. These investigations include creating formalization (i.e., mapping) rules for other target languages, codifying mapping rules in a more precise way, extending both the model development and analysis framework and the formalization framework to support timing, and developing patterns to guide model- ing and analysis of distributed real-time embedded systems. These ideas are further elaborated below. 0 Creating formalization (mapping) rules for other target languages. McUmber developed a general framework for formalizing ob ject-oriented mod- eling notations [31, 33]. The model development and analysis framework pre- sented in this dissertation leverages and integrates this formalization framework. 226 To demonstrate the flexibility of the formalization framework, McUmber cre- ated mapping rules from UML to both VHDL [30, 31], a simulation language used in embedded systems development, and Promela [31, 33], the input lan- guage for the model checker Spin [69]. The instantiation of the model develop- ment / analysis and formalization frameworks described in this dissertation uses his UML-to—Promela mapping rules [31, 33] and the Spin [69] model checker. Using McUmber’s metamodel-based approach to formalization, it would be pos- sible to create mapping rules to other target languages, such as SMV [75], to enable the use of other formal analysis tools. Model checkers for SMV (e.g., Cadence SMV [142], NuSMV [143, 144]) sup- port Computational Tree Logic (CTL), a branching-time temporal logic where temporal operators quantify over the paths possible from a given state, as well as LTL, a linear-time temporal logic where temporal operators describe events along a single path of computation. Because CTL and LTL are not expressively equivalent [5], a mapping to SMV would provide the potential for checking prop- erties previously not expressible with the Spin instantiation of the integrated frameworks, such as AC (EF p) [70], or the mutual-exclusion property described in Figure 11.1. Specification patterns [43] and some object analysis pattern constraints [53] also support CTL [145], so developers would still have some guidance when instantiating CT L properties. Currently, there are few UML formalizations to SMV (e.g., [146, 147, 148]). Codifying mapping rules more precisely. State—of-the-art formalization approaches (e. g., [26, 27, 31, 33, 146]) overwhelm- ingly use what we term correspondence-style rules [35] to define mappings from a source to a target language for every source language feature formalized. That is, each rule presents, in an inherently informal style, a prose description of the 227 Example: Consider an instance of the mutual exclusion problem, where each process P, has a non-critical section N C3,, a trying section TRY,, and a critical section C8,. It should be possible for a particular process P, either to remain in its non-critical section forever while other processes P, perform their tasks in a mutually exclusive fashion, or to eventually enter its trying section. The key property is that once P, is in N C3,, it either remains there forever or eventually enters TRY,, which can be expressed in CTL as EC(inNCS,-) /\ EF(inTRY,) /\ A(C(inNCS,-) V F(inTRY,)) (11.1) where path quantifiers A (“for all paths”) or E (“for some paths”) may prefix asser- tions composed of linear—time temporal operators G (“always”), F (“sometimes”), X (“next”), and U (“until”). Thus, Expression (11.1) states (in CTL) that for some paths, process P, is always in its non-critical section N C5,; and for some paths, pro- cess P, is sometimes in its trying section TRY,; and for all paths, process P, is either always in its non-critical section N CS, or sometimes in its trying section TRY,. Because LTL cannot explicitly express the existence of alternate computation paths, but only describe events along a single path, the closest candidate expression using the linear-time temporal operators described above for Expression (11.1) is Amalia/ca) v F(inTRY,-)), (11.2) which unfortunately allows for a degenerate model where all paths satisfy F (inTRY,), the possibility that process P, eventually enters its trying section, and no paths satisfy C(inNCS,), the possibility that process P, remains in its non-critical section forever. Using the LTL notation of Chapter 2, Expression (11.2) can be written as [I](inNCS,-) V <>(inTRY,). (11.3) Figure 11.1: Example CTL property not fully expressible in LTL [5] 228 context for instantiating the rule, and examples of the target-language code snippets to be generated. For example, Wang’s OMT-to—LOTOS formaliza- tion [27] and McUmber’s UML-to—Promela formalization [31, 33], described in this dissertation, both use this approach. However, recent investigations by Cheng et al. [35, 149] suggest that a combination of a natural deduction system (NDS) and metamodel—based approach to formalization has an advantage over correspondence-style rule-based ones in that NDS rules themselves can precisely capture a mapping from source- to target-language metamodels. Potentially ambiguous, inconsistent, and/ or incomplete correspondence-style rules, on the other hand, must first be interpreted by a human (an inherently error—prone step by itself) in order to be encoded into an executable tool. Cheng et al. [35] found that an N DS and metamodel-based approach forces developers to be explicit about assumptions when creating a set of formalization rules, and also revealed ambiguities and missing cases in an existing set of correspondence-style rules mapping a subset of UML to SMV [146]. Precisely codifying a mapping from UML to a given target language in a format amenable to automated reasoning (i.e., NDS rules) will enable unambiguous generation of a formal model from UML diagrams. Extending both frameworks to support timing. Konrad et al.’s preliminary work with validating timing—based embedded sys- tems requirements [54, 55] has shown that checking untimed properties is not sufficient for systems that rely critically on timing. For example, a property for a cruise control system that states that “it is always the case that if the driver taps the brake pedal, the cruise control system eventually disengages” does not include any timing information about the actual time delay that it takes from the activation of the brake until the disengagement of the system. Therefore, it is also necessary to check the property that “it is always the case that if 229 the driver taps the brake pedal, the cruise control system disengages within a specific time period.” Because (real-time) embedded systems frequently have strict timing constraints, methods for modeling and analyzing time-based re- quirements have value for embedded systems developers. Konrad et al. [54, 55] introduce a timer type in UML class diagrams and use a notation similar to timed automata [150] to add the ability to manipulate and evaluate timers in UML state diagrams. Correspondingly, they extend McUm- ber’s previous UML-to—Promela formalization [31, 33] to incorporate semantics similar to timed automata, using the digital-clock model [150]. The result is that requirements-based properties involving time (expressed in a subset of metric temporal logic (MTL) [151]) can be checked against the formal Promela model automatically generated from UML diagrams. Modified versions of Spin [152, 153] for analyzing timing have been developed, as well as other tools for the verification of real-time systems, such as Kro- nos [154] and HyTech [155]. However, these tools lack both a mapping from UML into their respective target languages, and a UML-based graphical editing and visualization environment. Therefore, these tools do not offer any support for the graphical UML-based modeling of a system nor for visualizing property violation traces in terms of UML diagrams. MIN ERVA’s graphical editors could be extended to support timing syntax, and Hydra’s automated generation of formal models could be extended to support timing semantics, at first using Konrad et al.’s extension to McUmber’s UML— to-Promela formalization [54, 55] described above, and then potentially using mappings to other target languages and tools that have built-in support for timing. Additionally, timing-based visualizations might be helpful for indicating when a particular property is violated. 230 0 Developing patterns for distributed real-time embedded systems. Given the potentially critical nature of embedded systems (e.g., X-by-wire, med- ical devices, etc.) in which faulty behavior of a system could lead to significant loss, methods for modeling and developing embedded systems and rigorously analyzing behavior before starting the design phase and committing to code are increasingly important. However, currently much of the embedded systems industry uses ad hoc development approaches [37] that emphasize design and coding over analysis [116]. The large number of design patterns [83], especially design patterns tailored to real-time systems (e.g., [104, 109, 110, 111, 114]), is further evidence of this focus. Despite its importance, the analysis phase is of- ten neglected in current embedded systems development practice, often causing conceptual errors to be propagated to design and coding [36]. To address this problem for (non-distributed) embedded systems, Konrad et al. propose object analysis patterns [1, 2, 3, 4] to be used in the analysis phase of development that not only guide developers in constructing UML-based conceptual models of their systems, but also provide property templates so that developers are able to validate these models, prior to design, using McUmber’s formalization framework [31, 33]. In Chapter 9, we discussed and demonstrated how these patterns can be used to drive our model development and analysis process from Chapter 4 by guiding both model construction and property instantiation. The demand for distributed real-time embedded systems (DREs) has increased considerably in recent years and is expected to continue to grow. DREs occur in many application domains, including automotive, aerospace, manufacturing, ‘ and telecommunication. The complexity of DREs has increased in order to add new services and features in an effort to keep these applications competitive in a global market. These embedded devices often operate in environments where a failure could lead to significant losses, such as human life or financial losses. The 231 increase in the number and complexity of DREs strongly motivates the need for more rigorous, repeatable, and cost-effective development techniques, of which patterns can play an important role. However, Konrad et al.’s object analysis patterns [1, 2, 3, 4] focus on an individual embedded system, rather than a collection of embedded systems that work cooperatively together as they would in a DRE. These patterns could be expanded significantly to address various concerns of the DRE domain, such as decentralized fault-handling, real-time hard timing constraints, concurrency, synchronization, and safety. 232 APPENDICES 233 Appendix A Wang’s Design Process In order to formalize OMT, Wang developed a systematic design process for con- structing and refining the object-oriented models [60]. The design process contains iterations of model development. For each step of model development during a given iteration, corresponding formal models are derived or refined (see Figure A.1). The process explicitly addresses the consistency between the formal models of two adjacent levels of abstraction thus enabling stepwise refinement and consistency checking [60]. In the design process, Steps 1-3 focus on creating system-level versions of object, dynamic, and functional models, respectively. Steps 4-7 are refinements and decom- _ positions of the models from Steps 1-3. An object functional model (OFM) in Step 5 is a variation of data flow diagrams, and it depicts visible services offered by the object. A service refinement functional model (SRFM) in Step 6b is also a variation of data flow diagrams, depicting a system/ object service in terms of the services pro- vided by the aggregate objects of the system/ object. Step 8 composes the dynamic models for all aggregate objects to depict the overall system behavior. The formal models of the diagrams enable automated analysis to check that the diagram and model refinements are consistent with earlier versions of diagrams and models. 234 (System) Object Model ll (System) Functional Model ll ll (System) Dynamic Model II 4/l g Refined (System) ‘ _' Object Model : Ir : 5/2 I < Object I Functional Model I [ Iterations II II 1 . . —— 0 Des: n 6b (la/3 ' l Rfefinetfzent Service Refinement Ollie“ : Functional Model Dynamic Model : If 3 Refined (System) E Dynamic Model ; 8 , Composed Parallel Dynamic Model Figure A.1: Wang’s iterative design process 235 Appendix B TRMCS Refinement The Teleseruices and Remote Medical Care System (TRMCS) design proposed in [46] is a distributed system that realizes its functionality via a collection of communicat- ing software components. The distributed operation is supported by a client-server architecture. The main components of interest examined in the refinement cooperate to realize the services expressed in the high-level model. This Appendix overviews object, service, and dynamic model refinement for the TRMCS to complement the discussion in Chapter 3 illustrating different LOTOS analyses. Object refinement. The system-level object model for the TRMCS is refined (according to Step 4 of Wang’s design process, Appendix A, Figure A.1, page 235) to include new objects as shown in bold in Figure B.1, where the diamond indicates aggregation and a filled circle indicates the “zero or more” relationship (see Chapter 2, Section 2.1.1, page 11, for more details on OMT syntax). As shown in Figure B.1, a Data Repository handles requests for patient records issued by Clients, while a Name Monitor is responsible for maintaining a list of active Data Repositories and handling Client requests for copies of this list. A Channel represents the connection between a Client object and any of the Data Repositories. LOTOS models (not shown) are derived for all of the aggregate objects in the same manner in which a LOTOS model 236 was derived for the high-level system (Chapter 3). TRMCS Select_Patient Retrieve__Profile Diagnose_Patient O Name_Monitor Register Get_ServerTable Client Data_Repository Query k: :1 3...... Channel Send Figure B.1: Refined TRMCS object model (attributes have been elided) Service refinement. The refinement of the high-level TRMCS into aggregate ob- jects Client, Data Repository, Name Monitor, and Channel allows us to refine the high- level Retrieve Profile service in the TRMCS object into a composition of services offered by the aggregates. TRMCS uses the Client’s Query service to implement the high-level Retrieve Profile service. Thus the client-server architecture suggests a re- finement of the dynamic model of the TRMCS system (Figure B2) to depict the Retrieve Profile service being handled by the Client’s Query service. The WaitQuery 237 ‘P‘. .l state is introduced to handle the redirection of the Query Request and the conversion of the returned Query Result as described below. The modified parts of the model (indicated by bold states or transition text outlined by dotted rectangles) specify that: 1. When a request for the high-level Retrieve Profile service occurs, the input argument Patient ID is decomposed into Data Repository Name and Query Request. 2. The Query Request is redirected to a Client object for a Query service. 3. The TRMCS system enters the WaitQuery state to await a Query Result from the Client. 4. When a Query Result is received from the Client, the TRMCS converts the Query Result to a Patient Record and delivers it to the user. Dynamic model refinement. As indicated in Step 8 of Wang’s design process (Appendix A, Figure A.1, page 235), the dynamic models of instantiations of all the aggregate objects and the TRMCS object are composed concurrently, and the refined Object-oriented models are again translated to LOTOS to create the refined model (not shown). For our case study [46], we composed the instantiated behaviors of one Client (Figure B.3), one Name Monitor (Figure B4), and one Channel (Figure 8.5) with the instantiated behaviors of two Data Repository instances (Figures B6 and B. 7). The behaviors of the Client, Name Monitor, Channel, and each Data Repository were instantiated as described in Figure B.8. We included two instances of Data Repository in order to validate correct con- current behavior for the distributed system. The two instances of Data Repository, LANSING and DETROIT, are fully interleaved. 238 Retrieve_Profile(ptID: Patient_ID) [not(isValidPtID(ptID))] - Select_Patient(ui: Userlnput) / Select_Patient(ui) ‘- —_-- —---—--———--‘_-q f l Retrieve_Profile(ptID: Patient_ID) [isValidPtID(ptID)] l | "Client.Query(PtID_getDataRepositoryName(ptID), | PtID_getQueryRequest(ptID)) !— _________ .5 __________ l Select_Patient(ui: Userlnput) (WaitQuera Select_Patient(ui: Userlnput) / Select_Patient(ui) / Select_Patient(ui) l Client.Query(qrs: Query_Result) Ll Retrieve_Prof1le(QueryResult2PatientRecord(qrs)) l Diagnose_Patient(diagreq: Diagnosis_Request) / Diagnose_Patient(diagreq) Figure B.2: Refined TRMCS high-level dynamic model (state diagram) 239 "Name_Monitor.GetTable() (Client_lnit) Name_Monitor.GetTable(st: Server_Table) Query(dm: Data_Repository_Name, qrq: Query_Request) "Name_Monitor.GetTable() (Client_ldle Client_WaitTable) N ame_Monitory.GetTable(st: Server_Table) [getAddress(st, drn) eq undef_Address] / Query(undef_Query_Result) Name_Monitory.GetTable(st: Server__Table) [not(getAddress(st, drn) eq undef_Address)] AData_Respository.Search(qrq, getAddress(st, drn)) Data_Repository.Search(qrs: Query_Result) / Query(qrs) Client_WaitQuery Figure B.3: Dynamic model (state diagram) of the TRMCS Client 240 Register(dm: Data_Repository_Name, a: Address) _, / Register(dm, a) o {NMPollingRQ GetTable/ GetTable() Figure 34: Dynamic model (state diagram) of the TRMCS Name Monitor Data_Repository_Search(qrq: Query_Request, a: Address) [a eq 1234] AData_Repository_S 1234(qrq, a) WaitCh1239 Data_Repository_S l 234(qrs: Query_Result) / Data_Repository_Search(qrs) Idle Data_Repository_85678(qrs: Query_Result) / Data_Repository_Search(qrs) WaitCh5679 Data_Repository_Search(qrq: Query_Request, a: Address) [3 eq 5678] AData_Repository_SS678(qrq, a) Figure 8.5: Dynamic model (state diagram) of the TRMCS Channel 241 Register(getRepositoryName(dr), getAddress(dr)) V DRPollingRQ Data_Repository_S 1234(qrq: Query_Request, a: Address) [not(tsMyAddress(a, dr))] Data_Repository_S 1234(qrq: Query_Request, a: Address) [isMyAddress(a, dr)] Search do/ Search(qrq) Figure 8.6: Dynamic model (state diagram) of first TRMCS Data Repository 242 Register(getRepositoryName(dr), getAddress(dr)) Y DRPollingRQ Data_Repository_S5678(qrq: Query_Request, a: Address) [not(isMyAddress(a, dr))] Data_Repository_SS678(qrq: Query_Request, a: Address) [isMyAddress(a, dr)] ( Search kdo/ Search(qrq) Figure B.7: Dynamic model (state diagram) of second TRMCS Data Repository Client make_Client(empty) Name Monitor make_Name_Monitor(empty) Channel make_Channe1 (empty) __First Data Repository make_Data-Repository(lansing, lansing_db, 1234) [icond Data Repository make_Data_Repository(detroit, detroit-db, 5678) Figure B.8: TRMCS LOTOS instantiations 243 Appendix C Formal Model Generator Architectures This Appendix compares both the architecture realized in Wang’s approach (Sec- tion C1) and the architecture realized in McUmber’s approach (Section G2) to the general formal model generator architecture first introduced in Chapter 4. C. 1 Wang’s Approach Figure C.1 illustrates the architecture realized in Wang’s approach as compared to the general formal model generator architecture (Figure C.1(a)) first introduced in Chapter 4. Wang created a set of mapping rules from OMT to LOTOS, shown as a bold solid rectangle in Figure C.1(b). Wang then augmented a simple Motif-based graphical editor for OMT class diagrams, VISUALSPECS [156], to add support for OMT state and data flow diagrams (shown as a bold solid oval in Figure C.1(b)). This augmented editor was, in future work, to have output an intermediate (textual) representation of OMT diagrams. Wang intended to write a parser for this inter- mediate representation in order to generate LOTOS models based on his mapping rules from OMT to LOTOS. These unfinished portions are shown as the bold dashed 244 intermediate representation data flow arrow and bold dashed Translator pro- cess oval in Figure C.1(b), respectively. The bold solid LOTOS model data flow arrow in Figure C.1(b) represents LOTOS models generated by manual application of Wang’s mapping rules. Finally, with this architecture it may be possible to ana- lyze some types of properties against the generated formal model as represented by the dot—dashed data flows and solid properties rectangle in Figure C.1(a). As an example of a type of property that can be analyzed with LOTOS analysis tools, such as the TOPO / LOLA LOTOS tool shown in Figure C.1(b), a developer can compose a test process (solid rectangle between dashed data flows) with a LOTOS model to check whether the behavior described by the test process is present in the model. An example of test composition is described in Chapter 3, page 36. User input for graphical diagram(s) Graphical Editor Intermediate representation of diagram(s) Prose requirements Trans Iator Mapping rules for fomial language ' model _ Fomial Language 1 Properties """""""""" Analysis Tool(s) l _1 Analysis 3 results (raw) (a) General architecture User input for graphical diagram(s) OMT Graphical Editor Prose requirements ' Intermediate representation ' 0‘ diagram(s) - - ~ . Q ' Translator s‘ .' Mapping rules ‘ for LOTOS , l ‘9 model Test ___________ - (TOPO/LOLA) LOTos Process AMIYSIS Tool(s) i Analysis results (raw) (b) Wang’s approach Figure C.1: Architecture for formal model generator realized in Wang’s approach C.2 McUmber’s Approach Figure C.2 illustrates the architecture realized in McUmber’s approach as compared to the general formal model generator architecture (Figure C.2(a)) first introduced in Chapter 4. As represented by the bold solid intermediate representation data flow in Figure C.2(b), McUmber created a textual representation language of UML class and state diagrams, called Hydra Intermediate Language (HIL). As his 'IYanslator, he created a parser for HIL, Hydra [31], to generate both VHDL and Promela models (each target language had its own set of mapping rules). Figure C.2(b) shows Hydra (a bold solid oval) instantiated with his mapping rules for Promela (a bold rectangle). The instantiation shown generates Promela models, as represented by the bold solid Promela model data flow arrow. He did not create a graphical editor for UML that would output HIL; thus, the UML Graphical Editor is shown as a bold dashed process oval in Figure C.2(b). Finally, with this architecture it may be possible to analyze some types of properties against the generated formal model as represented by the dot-dashed data flows and solid properties rectangle in Figure C.2(a). As an example of a type of property that can be analyzed with Promela analysis tools, such as the Spin tool shown in Figure C.2(b), a developer can check LTL properties (solid rectangle between dashed data flows) against a Promela model. An example of checking LTL properties is described in Chapter 7. 246 Prose req u i reme nts Properties l'“ User input for graphical diagram(s) Graphical Editor Intermediate representation of diagram(s) Translator Mapping rules for formal language Q Fomial "’ model Formal Language Analysis Tool(s) : Analysis 3 results (raw) (a) General architecture Prose requirements LTL ........... Properties User Input for graphical diagram(s) ' ‘ — u - ~ ~ " UML \ ‘ Graphical Edltor ’1 ~ ~ ' -“ Intermediate representation of diagram(s) Hydra Mapping rules for Promela (SPIN) Promela Analysis Tool(s) 3 Analysis 3 results (raw) ..................................... (b) McUmbers’s approach Figure C.2: Architecture for formal model generator realized in McUmber’s approach 247 Appendix D Adaptive Cruise Control Attributes and Signals trail distance closing zone . 1 l , I 7 fl safety zone coast zone I J l J I I I I [ C} j H I :33 lead / \ I f Car vehicle 21 22 xhit: xcoast: xl _.—qp__ direction of travel Figure D.1: Variables and zones used by Adaptive Cruise Control Control algorithm. Scales 0 Time is measured in seconds. 0 Distance is measured in tenths of a foot. 0 Speed is measured in tenths of a foot per second. 248 Signals o All signals are asynchronous. o Signals that carry parameters include each parameter type in the signal signa- ture. Glossary 0 Car: Adaptive Cruise Control-equipped vehicle. 0 Lead vehicle (also called the target vehicle): Vehicle encountered in front of the Car. 0 T rail distance: Distance the lead vehicle travels in a given amount of time (usually two seconds). 0 Safety zone: 90% of the specified trail distance. 0 Closing zone: Zone in which the Radar has acquired the lead vehicle as a target, but the Car has not yet achieved proper trail distance behind the lead vehicle. 0 Coasting: Continued (forward) movement without throttle. 0 Closing speed: Speed at which the Car approaches the lead vehicle. In a typical scenario, the Car approaches a slower moving lead vehicle at the set cruising speed, but will not begin decelerating until the Control algorithm’s relative speed and distance calculations determine that coasting should be initiated. 0 Coast zone: Zone in which the Car is coasting. 0 Adjusted speed: Speed calculated by the Control algorithm. The Control algo- rithm simulates adjusting the Car’s throttle by calculating a new (increased or decreased) speed for the Car. 249 Car Attributes Attribute Description setv Adjusted speed of the Car as set by the Control algorithm. For modeling purposes, this speed is initially set to 1100 tenths of a foot per second. realv Current speed of the Car. For modeling purposes, this speed is initially set to 1100 tenths of a foot per second. Figure D2: Car attributes Car Signals Signal Description carv Developer error: Should have been getv. Detected and corrected in Section 7.3. setspeed( int ) Signal (from the Control) Whose parameter is the adjusted speed of the Car as set by the Control algorithm. unset Signal from the Control indicating the beginning of the cruise control disengagement process. getv Signal from the Radar requesting the current speed of the Car. getspeed Signal from the Control requesting the current speed of the Car. Figure D.3: Car signals 250 Radar Attributes Attribute Description v Closing speed of the Car. Used by the Radar simulation algo— rithm to calculate the next sampled distance to the target vehi- cle. Calculated as v = vc — vt. vc Most recent Car speed as obtained from the Car. vt (Constant, 900) Speed of the target vehicle. x Current distance to the target vehicle. Calculated as :1: = x — 2) every time the Radar simulates sampling the distance to the target vehicle (assumed to be once per second). For modeling purposes, this distance is initially set to 4500 tenths of a foot, greater than the range of the Radar (4000 tenths of a foot). tmode Boolean flag used by the Radar simulation algorithm. Set to true when Radar acquires a target. Figure D.4: Radar attributes Radar Signals Signal Description ackcontrol Acknowledgment signal received from the Control in response to target, dist, and lost signals. on Signal received from the Control indicating that the Radar should be turned on. ofl Signal received from the Control indicating that the Radar should be turned off. carv( int) Signal (received from the Car) whose parameter is the current speed of the Car. ackcar‘ Unused signal. acksys Unused signal. Figure D.5: Radar signals 251 Control Attributes Attribute Description a (Constant, 15) Acceleration/ deceleration adjustment to the speed of the Car. closing Boolean flag used in the Control algorithm. Set to true when the Control algorithm’s relative speed and distance calculations determine that coasting should be initiated. setspeed Developer error: Should have been setspd. Detected and cor- rected in Section 7.3. setspd Cruising speed set by the driver. tinc (Constant, 1) Increment of time (in seconds) between Radar dis- tance samples. tmin (Constant, 2) The number of seconds of target vehicle travel used to calculate the desired trail distance. v Calculated closing speed of the Car as it approaches the target vehicle. Calculated as v = (51:1 — 2:2)/tinc. vc Current speed of the Car. Obtained from the Car. vt: Calculated current speed of the target vehicle. Calculated as at = '00 — '0. x1 Previous sampled distance to the target vehicle as obtained from the Radar. After i), vt, 22, and 21 are calculated in a single cycle of the Control algorithm, 231 is set equal to 3:2 in Control state getxc. x2 Current sampled distance to the target vehicle as obtained from the Radar. xcoast Calculated distance from the target vehicle at which to start coasting in order to achieve the desired trail distance. Calculated as :rcoast = :rhit + 22 + tine * 1!. xhit Calculated distance from the target vehicle at which to start coasting in order for the Car to exactly match the speed of the target vehicle at zero trail distance. Calculated as xhit = (v * v) / (2 * a). 21 Calculated closest safe distance from the target vehicle. Bound- ary of the safety zone. Calculated as 90% of the desired trail distance, or 21 = 22 -— (22/10). 22 Calculated desired trail distance from the target vehicle. Calcu- lated as 22 = vt * tmin. Figure D.6: Control attributes 252 Control Signals Signal Description ackcar Acknowledgment signal received from the Car in response to setspeed and unset signals. acki‘adar Acknowledgment signal received from the Radar in response to an on signal. brakes External signal that simulates the driver has applied the brakes. carspeed{ int) Signal (received from the Car) whose parameter is the current speed of the Car. dist( int ) Signal (received from the Radar) whose parameter is the current distance from the target vehicle. lost Signal received from the Radar indicating that a previously ac- quired target has been lost. set External signal that simulates the driver has set the desired cruising speed. target Signal received from the Radar indicating that a target has been acquired. Figure D.7: Control signals 253 Ac Appendix E Adaptive Cruise Control Control State Diagram The modified Control state diagram as described in Section 7.4.4 includes transitions that handle the brakes message (shown as dashed arcs). The missing transition from state caroff to handle the carspeed message is shown in bold. Due to printing limitations, the transitions have been annotated with unique numbers that correspond to the legend in Figure 13.1. 254 H, -. ‘II a. 1 . lllitLCldta Y... in. st i... nut. ..U Is 3s «A. 1‘ x. . a s x; .3. c. . ..... I. 7.. .3. 6.» 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 "_SYSTEMCLASS_ . ready set [1 / ‘Car.getspeed carspeed(setspd) [J / “Car.setspeed(setspd) ackcar [J / “Radar.on ackradar [] / target [J / “Radar.ackcontrol lost [J / ackcar [J / ‘Radar.ackcontrol dist(xl) [J / xcoast :=O lost [J / dist(x2) [] / carspeed(vc) [] / ["closing] / xhit:=(v*v)/(2*a); xcoast:=xhit+z2+tinc*v [closing] / [x1 >= 21] / [xhit <= x1] / [xhit > X1] / [l / [closing] / [”closing] / [x1 > xcoast] / [x1 <= xcoastJ / closing =1 ‘Car.setspeed(vt) ackcar [J / brakes [J brakes [J brakes [J brakes [J brakes [J brakes [J / carspeed(vc) [J / lost [J / dist(xl) [] / target [1 / ackcar [J / [x1 < 21] / “Car.unset brakes [J / ackcar [J / ‘Radar.off \\\\\ Figure 13.1: Legend for transitions in Figure E2 255 S #4“ ' """""""" #846,er 6 2 21¢ch send(Car.setspeed(setspd)) l 1 J I I l i I I l l :- ------------ getxl l i 10 : t .. ................ . 9 l i g 1 F getxc \ l l i getspd entry/ v '= (x1 - x2) / tinc l E ' entry/ send(Radar.ackcontrol) ' ,_ : . N , entry/ vt .— vc - v : E g, 1'1 F—H entry/ 22 := vt * tmin 37 E g l calc 12 entry/ zl := z2 — (22/ 10) 34 E l “""i-“Cntry/ send(Car.getspeQ—l \ entry/ XI := x2 j I E l ' 2. L13 L14 E : ' 23 l E 2'6 19 close l6 warn 15 : . , . E E l 20 35 l i 27 24 i . , 18 sendwam 17 t“ : waiting 3.6 alloff 25 .- ---29- 30 I . ‘I . : t l— ‘—@22 3 caroff I 23 entry/ send(Radar.off) I t, .- ' ------------ entry/ send(Car.unset) u """"""""""""" ' IL ............................... . I ................................... ' L32_l L33 Figure E2: State diagram for the Adaptive Cruise Control class Control 256 Appendix F Hydra-Generated Promela Code for Adaptive Cruise Control This appendix contains the Promela model for class Control and its state diagram. (This code has been excerpted from the Promela model automatically generated for the Adaptive Cruise Control UML diagrams in Chapter 7.) Extra linebreaks have been added in order to ensure that the formal model is readable; no attempt has been made to add additional comments to annotate the formal model. The inclusion of the formal model is intended to illustrate the correspondence between the UML diagrams and the Promela code. 1typedef Control_T { 2 int a; 3 int tmin; 4 int vc; 5 int x1; 6 int vt; 7 int tinc; 8 int x2; 9 bool closing; 257 If) ' I 10 int v; 11 int z1; 12 int xhit; 13 int 22; 14 int setspd; 15 int xcoast; 16 } 17Control_T Control_V; ischan Control_q=[5] of {mtype}; igchan Control_carspeed_p1=[5] of {int}; zochan Control_dist_p1=[5] of {int}; n 22proctype Control() 23{ 24mtype m; 25int dummy; 2s Control_V.a = 15; 27 Control_V.tmin = 2; 23 Control_V.tinc = 1; 29/* Init state */ 30/* Initial actions / messages */ 31 _SYSTEMCLASS__q!ready; 32 goto idle; 33/* State idle */ 34idle: printf("in state Control.idle\n"); 35 atomic {if :: !t?[free] -> t!free :: else skip fi;} 36 if 37 :: Control_q?set -> t?free; Car_q!getspeed; goto gotit 33 fi; 39/* State gotit */ 4ogotit: printf("in state Control.gotit\n"); 41 atomic {if :: !t?[free] -> tlfree :: else skip fi;} 42 if 43 :: atomic{Control_q?carspeed —> 14 Control_carspeed_p1?Control_V.setspd} -> t?free; 45 atomic{Car_setspeed_p1!Control_V.setspd; Car_q!setspeed}; 45 goto setitO 47 fi; 45/* State caroff */ 49caroff: printf("in state Control.caroff\n"); 55/* entry actions */ 51 atomic{ 52 Radar_q!off;Car_q!unset; 53 } 54 atomic {if :: !t?[free] -> tlfree :: else skip fi;} 55 if 55 :: atomic{Control_q?carspeed -> 57 Control_carspeed_p1?Control_V.vc} -> t?free; goto caroff 55 :: Control_q?ackcar -> t?free; goto idle 59 :: atomic{Control_q?dist -> Control_dist_p1?Control_V.x1} -> 55 t?free; goto caroff 51 :: Control_q?brakes -> t?free; goto caroff 52 :: Control_q?target -> t?free; goto caroff 53 :: Control_q?lost -> t?free; goto caroff 54 fi; 55/* State getxc */ 55getxc: printf("in state Control.getxc\n"); 57/* entry actions */ 259 55 atomic{ 59 Control_V.v=(Control_V.x1-Control_V.x2)/Control_V.tinc; 7o Control_V.vt=Control_V.vc-Control_V.v; 71 Control_V.z2=Control_V.vt*Control_V.tmin; 72 Control_V.21=Control_V.z2-Control_V.z2/10; 79 Control,V.x1=Control_V.x2; 74 } 75getxc_G: 75 atomic {if :: !t?[freeJ -> t!free :: else skip fi;} 77 if 75 :: 1 -> t?free; if 79 :: Control_V.closing -> goto alarm 51 :: !Control_V.closing -> 51 Control_V.xhit=(Control-V.v*Control_V.v)/(2*Control_V.a); 52 Control_V.xcoast=Control_V.xhit+Control_V.22+ 53 Control_V.tinc*Control_V.v; 54 goto alarm 55 :: else -> goto getxc_G 55 fi 57 fi; 55/* State alarm */ 59a1arm: printf("in state Control.alarm\n"); 9oalarm_G: 91 atomic {if :: !t?[free] -> tlfree :: else skip fi;} 92 if 93 :: 1 -> t?free; if 94 :: Control_V.x1 Car_q!unset; goto alloff 95 :: Control-V.x1>=Control_V.21 -> goto warn 95 :: else -> goto alarm_G 260 97 fi 98 fi; 99/* State alloff */ 1m1alloff: printf("in state Control.alloff\n"); 191 atomic {if :: !t?[freeJ -> tlfree :: else skip fi;} m2 if m3 :: Control_q?ackcar -> t?free; Radar_qloff; goto idle m4 :: Control_q?brakes -> t?free; goto alloff w5 fi; m5/* State warn */ m7warn: printf("in state Control.warn\n"); mswarn_G: m9 atomic {if :: !t?[free] -> t!free :: else skip fi;} no if 111 t: 1 -> t?free; if n2 :: Control_V.xhit>Control_V.x1 -> goto sendwarn n3 :: Control_V.xhit<=Control_V.x1 -> goto close n4 :: else -> goto warn_G 115 fi no fi; n7/* State close */ u5close: printf("in state Control close\n"); n9close_G: in) atomic {if :: !t?[free] -> tlfree :: else skip fi;} 121 if 122 :: 1 -> t?free; if 123 :: !Control_V.closing -> goto waiting m4 :: Control_V.closing -> goto getspd 125 :: else -> goto close_G 261 126 fi 127 fi; m5/* State sendwarn */ m9sendwarn: printf("in state Control.sendwarn\n"); no atomic {if :: !t?[free] -> tlfree :: else skip fi;} 131 if m2 :: 1 -> t?free; goto close 133 fi; m4/* State waiting */ 1' waiting: printf("in state Control.waiting\n"); (I. 0" mswaiting_G: m7 atomic {if :: !t?[free] -> t!free :: else skip fi;} me if we :: 1 —> t?free; if no :: Control_V.x1<=Control_V.xcoast -> m1 Control_V.closing=1; M2 atomic{Car_setspeed_p1!Control_V.vt; Car_q!setspeed}; M3 goto ac N4 :: Control_V.x1>Control_V.xcoast -> goto getspd m5 :: else -> goto waiting_G M6 fi m7 fi; m5/* State ac */ mgac: printf("in state Control.ac\n"); mo atomic {if :: !t?[free] -> tlfree :: else skip fi;} 151 if wz :: Control_q?ackcar -> t?free; goto getspd ws :: Control_q?brakes —> t?free; goto caroff 154 fi; 262 m5/* State getspd */ 'f wegetspd: printf("in state Control.getspd\n"); w7/* entry actions */ 158 159 160 161 162 163 164 165 166 167 atomic{ Radar_q!ackcontrol; } atomic {if :: !t?[free] -> tlfree :: else skip fi;} if °: atomic{Control_q?dist -> Control_dist_p1?Control_V.x2} -> t?free; goto calc ': Control_q?brakes -> t?free; goto caroff ': Control_q?lost -> t?free; goto ackcarO fi; ms/* State calc */ 169 calc: printf("in state Control.calc\n"); no/* entry actions */ 171 172 173 174 176 177 I78 179 atomic{ Car_q!getspeed; } atomic {if :: !t?[freeJ -> t!free :: else skip fi;} if ': atomic{Control_q?carspeed -> Control_carspeed_p1?Control_V.vc} -> t?free; goto getxc ': Control_q?brakes -> t?free; goto caroff fi; m0/* State setitO */ 151setit0: printf("in state Control.setit0\n"); 182 183 atomic {if :: !t?[free] -> tlfree :: else skip fi;} if 263 w4 :: Control_q?ackcar -> t?free; Radar_q!on; goto setitl 185 fi; 186 /* State setitl */ m7setit1: printf("in state Control.setit1\n"); m5 atomic {if :: !t?[free] -> tlfree :: else skip fi;} 189 if we :: Control_q?ackradar —> t?free; goto maintain 191 fi; m2/* State ackcarO */ 191ackcar0: printf("in state Control.ackcar0\n"); w4/* entry actions */ 195 atomic{ m5 atomic{Car_setspeed_p1!Control_V.setspd; Car_qlsetspeed}; wr } ms atomic {if :: !t?[free] -> tlfree :: else skip fi;} 199 if m9 :: Control_q?ackcar -> t?free; Radar_q!ackcontrol; goto m1 maintain 202 fi; ma/* State maintain */ 2a1maintain: printf("in state Control.maintain\n"); m5 atomic {if :: !t?[free] -> t!free :: else skip fi;} 205 i f m7 :: Control_q?brakes -> t?free; goto caroff m5 :: Control_q?target -> t?free; Radar_q!ackcontrol; goto getxl 209 f i ; mo/* State getxl */ 211getx1: printf("in state Control.getx1\n"); m2 atomic {if :: !t?[free] -> t!free :: else skip fi;} 264 213 if ll !: 2m :: atomic{Control_q?dist -> Control_dist_p1?Control_V.x1} -> as t?free; m5 Control_V.xcoast=O;Control_V.closing=0; goto getspd m7 :: Control_q?brakes -> t?free; goto caroff m5 :: Control_q?lost -> t?free; goto ackcarO m9 fi; noexit: Skip all 265 121.1 1111" 0:)- pr: 1(le llCi\ Appendix G Hydra—Generated Promela Code for Producer- Consumer This Appendix contains four versions of the formal (Promela) model for the Producer- Consumer example. The first version is the baseline, generated according to formal- ization rules and without pushing additional diagram information into the formal model. The next three versions were generated according to the three breadcrumb options, states, transitions, and both, respectively. In the latter three versions, each printf for STATE and TRANSITION information was manually wrapped at the charac- ter ‘(9’ for readability in this Appendix (e.g., lines 37—38 and 44—47 in Section G.4); however, when generated, a printf statement appears all on one line of code. G. 1 Baseline 1#define min(x,y) (xx:y) 2#define max(x,y) (x>y->x:y) schan evq=[10] of {mtype,int}; achan evt=[1OJ of {mtype,int}; schan wait=[1OJ of {int,mtype}; 266 5mtype={demand, 0K, supply}; 7chan _SYSTEMCLASS__q=[5] of {mtype}; stypedef Producer_T { 9 int limited_ed; 19 int num_made; 11 } 12Producer_T Producer_V; 13chan Producer_q=[5] of {mtype}; 14typedef Consumer_T { 15 int edition_num; 15 } 17Consumer_T Consumer_V; 15chan Consumer_q=[5] of {mtype}; 19chan Consumer_supply_p1=[5] of {int}; m1chan t=[1J of {mtype}; 21mtype={free}; 22active proctype _SYSTEMCLASS_() 23{ 24 mtype m; zsint dummy; 25/* Init state */ 27 goto Create_Producer; 25/* State Create_Producer */ m1Create_Producer: printf("in state _SYSTEMCLASS_.Create_Producer\n"); M)/* entry actions */ 31 atomic{ 32 run Producer(); 33 } 34 atomic {if :: !t?[freeJ -> tlfree :: else skip fi;} 267 35 if n- 35 :: _SYSTEMCLASS__q?0K -> t?free; goto Create_Consumer 37 fi; 35/* State Create_Consumer */ 39Create_Consumer: printf("in state _SYSTEMCLASS_.Create_Consumer\n"); 49/* entry actions */ 41 atomic{ 42 run Consumer(); 43 } 44 atomic {if :: !t?[free] -> tlfree :: else skip fi;} 45 if 45 :: _SYSTEMCLASS__q?OK -> t?free; goto Done 47 fi; 45/* State Done */ 49Done: printf("in state _SYSTEMCLASS_.Done\n"); 55 atomic {if :: !t?[freeJ -> tlfree :: else skip fi;} 51 if 52 :: skip -> false 53 fi; 54exit: skip 55} m 57 55proctype Producer() 59{ somtype m; 51int dummy; 52 Producer_V.limited_ed = 5; 53/* Init state */ 268 54/* Initial actions / messages */ un' 55 _SYSTEMCLASS--q!OK; 55 goto Waiting_For_Demand; 57/* State Waiting_For_Demand */ 55Waiting_For_Demand: printf("in state Producer.Waiting_For_Demand\n"); 59Waiting_For_Demand_G: 7o atomic {if :: !t?[free] -> t!free :: else skip fi;} 71 if 72 :: Producer_q7demand -> t?free; if 73 :: Producer_V.num_made u Producer_V.num_made=Producer_V.num_made+1; goto 75 Advertise 75 :: else -> goto Waiting_For_Demand_G 77 - fi 75 :: 1 -> t?free; if m :: Producer_V.num_made>=Producer_V.limited_ed -> goto 59 Sorry-Sold_0ut 51 :: else -> goto Waiting_For_Demand_G 52 fi 83 fi; 54/* State Sorry_Sold_0ut */ 55$orry_Sold_0ut: printf("in state Producer.Sorry_Sold_0ut\n"); 55 atomic {if :: !t?[freeJ -> tlfree :: else skip fi;} 57 if 55 :: skip —> false 59 fi; 99/* State Advertise */ 91Advertisezprintf("in state Producer.Advertise\n"); 92 atomic {if :: !t?[free] -> t!free :: else skip fi;} 269 93 if 94 :: 1 -> t?free; 95 atomic{Consumer_supply_p1!Producer_V.num_made; 95 Consumer_qlsupply}; goto Waiting_For_Demand 97 fi; 95exit: skip 99} mo 1m m2proctype Consumer() m3{ m4mtype m; msint dummy; m5/* Init state */ m7/* Initial actions / messages */ m5 _SYSTEMCLASS__q!0K; m9 goto Have_Money_Will_Spend; n0/* State Have_Money_Will_Spend */ 111Have_Money_Will_Spend: n2 printf("in state Consumer.Have_Money_Will_Spend\n"); n3 atomic {if :: !t?[freeJ -> tlfree :: else skip fi;} n4 if n5 :: 1 -> t?free; Producer_qldemand; goto Waiting_For_Supply n5 fi; n7/* State Waiting_For_Supply */ n5Waiting_For_Supply: printf("in state Consumer.Waiting_For_Supply\n"); n9 atomic {if :: !t?[free] -> tlfree :: else skip fi;} no if 121 :: atomic{Consumer_q?supply -> 270 m2 Consumer_supply_p1?Consumer_V.edition_num} -> t?free; i— ma goto Have_Money_Will_Spend m4 fi; nsexit: skip we} I27 129 M9/* This is the universal event dispatcher routine */ 131proctype event(mtype msg) w2{ M3 mtype type; M4 int pid; M5 M5 atomic { M7 do M5 :: evq??[eval(msg),pid] -> M9 evq??eval(msg),pid; M5 evt!msg,pid; M1 do M2 :: if M3 :: evq??[type,eval(pid)] -> evq??type,eval(pid) M4 :: else break; M5 fi M5 od M7 :: else -> break M5 od} M9exit: skip mo} 271 (3.2 UML States 1#define min(x,y) (xx:y) 2#define max(x,y) (x>y->x:y) 3chan evq=[10] of {mtype,int}; 4chan evt=[10] of {mtype,int}; schan wait=[10] of {int,mtype}; 5mtype={demand, 0K, supply}; 7chan _SYSTEMCLASS__q=[5] of {mtype}; 5typedef Producer_T { 9 int limited_ed; 19 int num_made; II } 12Producer_T Producer_V; 13chan Producer_q=[5] of {mtype}; 14typedef Consumer_T { 15 int edition_num; 15 } 17Consumer_T Consumer_V; 15chan Consumer_q=[5] of {mtype}; 19chan Consumer_supp1y_p1=[5] of {int}; 29chan t=[1J of {mtype}; 21mtype={free}; 22active proctype _SYSTEMCLASS_() 23{ 24mtype m; 25int dummy; 25/* Init state */ 27 goto Create_Producer; 272 4.-' 25/* State Create_Producer */ 29Create_Producer: printf("in state _SYSTEMCLASS_.Create_Producer\n"); 39/* entry actions */ 31 atomic{ 32 printf("STATE@_SYSTEMCLASS_@209130692280324 33 ©Create_Producer©209130704732175\n"); 34 run Producer(); 35 } 35 atomic {if :: !t?[free] -> t!free :: else skip fi;} 37 if 35 :: _SYSTEMCLASS__q?DK -> t?free; goto Create_Consumer 39 fi; 49/* State Create_Consumer */ 41Create-Consumer: printf("in state _SYSTEMCLASS_.Create_Consumer\n"); 42/* entry actions */ 43 atomic{ 44 printf("STATE@_SYSTEMCLASS_@209130692280324 45 ©Create_Consumer©209130704732176\n"); 45 run Consumer(); 47 } 45 atomic {if :: !t?[free] -> tlfree :: else skip fi;} 49 if 59 :: _SYSTEMCLASS__q?0K -> t?free; goto Done 51 fi; 52/* State Done */ 53Done: printf("in state _SYSTEMCLASS_.Done\n"); 54/* entry actions */ 55 atomic{ 55 printf("STATE©_SYSTEMCLASS_@209130692280324 273 57 ©Done©209130706632727\n"); E 55 } 59 atomic {if :: !t?[free] -> t!free :: else skip fi;} 50 if 51 :: skip -> false 52 fi; 53exit: skip 54} 55 55 57proctype Producer() 55{ 59mtype m; mintdmmw; 71 Producer_V.limited_ed = 5; 72/* Init state */ 73/* Initial actions / messages */ 74 _SYSTEMCLASS__q!OK; 75 goto Waiting_For_Demand; 75/* State Waiting_For_Demand */ 77Waiting_For_Demand: printf("in state Producer.Waiting_For_Demand\n"); 75/* entry actions */ 79 atomic{ 59 printf("STATEQProducerQQOQ130692280326 51 QWaiting_For_Demand©209130753228840\n"); 52 } 53Waiting_For_Demand_G: 54 atomic {if :: !t?[free] -> t!free :: else skip fi;} 85 if 274 55 :: Producer_q?demand -> t?free; if 57 :: Producer_V.num_made 55 Producer_V.num_made=Producer_V.num_made+1; goto 59 Advertise 99 :: else -> goto Waiting_For_Demand_G 91 fi 92 :: 1 —> t?free; if 93 :: Producer_V.num_made>=Producer_V.limited_ed -> goto 94 Sorry_Sold_0ut 95 :: else -> goto Waiting_For_Demand_G 95 fi 97 fi; 95/* State Sorry_Sold_Out */ 99Sorry_Sold_0ut: printf("in state Producer.Sorry_Sold_Out\n"); mo/* entry actions */ 191 atomic{ m2 printf("STATE©Producer©209130692280326 m3 @Sorry_Sold_0ut@209130817257516\n"); um } M5 atomic {if :: !t?[free] -> t!free :: else skip fi;} me if m7 :: skip -> false m5 fi; m9/* State Advertise */ M9Advertisezprintf("in state Producer.Advertise\n"); 111/* entry actions */ n2 atomic{ n3 printf("STATEQProduceIQ209130692280326 n4 @Advertise6209130817257519\n"); 275 115 } 5 g, M5 atomic {if :: !t?[free] -> t!free :: else skip fi;} M7 if M5 :: 1 -> t?free; M9 atomic{Consumer_supply_p1!Producer_V.num_made; M9 Consumer_qlsupply}; goto Waiting_For_Demand M1 fi; M2exit: skip n3} M4 M5 M5proctype ConsumerC) n7{ M5mtype m; 121int dummy; M9/* Init state */ 131/* Initial actions / messages */ M2 _SYSTEMCLASS__q!DK; M3 goto Have_Money_Will_Spend; M4/* State Have_Money_Will_Spend */ M5Have_Money_Will_Spend: M5 printf("in state Consumer.Have_Money_Will_Spend\n"); M7/* entry actions */ M5 atomic{ M9 printf("STATEQConsumer©209130692280330 M9 @Have_Money_Will_Spend@209130736058394\n"); M1 } M2 atomic {if :: !t?[free] -> t!free :: else skip fi;} 143 if 276 M4 :: 1 -> t?free; Producer_qldemand; goto Waiting_For_Supply M5 fi; M5/* State Waiting_For_Supply */ 147Waiting_For_Supp1y: printf("in state Consumer.Waiting_For_Supply\n"); M5/* entry actions */ M9 atomic{ Mo printf("STATEQConsumeIQ209130692280330 M1 ©Waiting_For_Supply@209130747068447\n"); M2 } M3 atomic {if :: !t?[free] -> t!free :: else skip fi;} M4 if M5 :: atomic{Consumer_q?supply —> M5 Consumer_supply_p1?Consumer_V.edition_num} -> t?free; M7 goto Have_Money_Will_Spend M5 fi; M9exit: skip m0} 161 162 163 M4/* This is the universal event dispatcher routine */ M5proctype event(mtype msg) me{ M7 mtype type; M5 int pid; M9 M9 atomic { n1 do n2 :: evq??[eval(msg),pid] —> 277 173 174 175 176 150 151 182 183 exit: 184 } od} evq??eval(msg),pid; evt!msg,pid; do ': if ': evq??[type,eval(pid)] -> evq??type,eval(pid) ': else break; fi od ': else —> break skip G.3 UML Transitions 1#define min(x,y) (xx:y) 2#define max(x,y) (x>y->x:y) 3chan evq=[10J of {mtype,int}; 4chan evt=[10] of {mtype,int}; schan wait=[10] of {int,mtype}; 5mtype={demand, 0K, supply}; 7chan -SYSTEMCLASS_-q=[5] of {mtype}; 5typedef Producer_T { 9 10 11 i i } nt limited_ed; nt num_made; 12Producer_T Producer_V; 13chan Producer_q=[5] of {mtype}; 14typedef Consumer_T { 278 15 int edition_num; [I 15 } 17Consumer_T Consumer_V; 15chan Consumer_q=[5] of {mtype}; 19chan Consumer_supply_p1=[5] of {int}; 29chan t=[1J of {mtype}; 21mtype={free}; 22active proctype _SYSTEMCLASS-() 23f 24mtype m; 25int dummy; 25/* Init state */ 27/* Initial actions / messages */ 25 printf("TRANSITIONQ209130706632721@_SYSTEMCLASS_ 29 @2091306922803246Initial 39 @209130704732174©Create_Producer 31 0209130704732175©modelstart\n"); 32 goto Create_Producer; 33/* State Create_Producer */ 34Create_Producer: printf("in state _SYSTEMCLASS_.Create_Producer\n"); 35/* entry actions */ 35 atomic{ 37 run Producer(); 35 } 39 atomic {if :: !t?[free] -> t!free :: else skip fi;} 49 if 41 :: _SYSTEMCLASS__q?DK -> t?free; 42 printf("TRANSITIDNG209130706632723©_SYSTEMCLASS- 43 @209130692280324©Create_Producer 279 44 45 46 47 @209130704732175@Create_Consumer @20913070473217600K\n"); goto Create_Consumer fi; 45/* State Create_Consumer */ 49Create_Consumer: printf("in state _SYSTEMCLASS_.Create_Consumer\n"); 55/* entry actions */ 51 53 54 55 56 57 58 59 60 61 62 atomic{ run ConsumeIC); } atomic {if :: !t?[free] -> t!free :: else skip fi;} if ': _SYSTEMCLASS__q?0K -> t?free; printf("TRANSITIONQQOQ130706632725@_SYSTEMCLASS- @209130692280324QCreate_Consumer ©209130704732176©Done ©209130706632727©0K\n"); goto Done fi; 53/* State Done */ 64Done: 65 66 67 68 59exit: 79} 71 72 printf("in state _SYSTEMCLASS_.Done\n"); atomic {if :: !t?[freeJ -> t!free :: else skip fi;} if °: skip -> false fi; skip 280 73proctype Producer() 74{ 75mtype m; 75int dummy; 77 Producer_V.limited_ed = 5; 75/* Init state */ 79/* Initial actions / messages */ 59 printf("TRANSITIONQZOQ130753228837©Producer 51 6209130692280326©Initia1 52 @2091307532288396Waiting_For_Demand 53 @209130753228840©modelstart\n"); 54 _SYSTEMCLASS__q!OK; 55 goto Waiting_For_Demand; 55/* State Waiting_For_Demand */ 57Waiting_For_Demand: printf("in state Producer.Waiting_For_Demand\n"); 55Waiting_For_Demand_G: 59 atomic {if :: !t?[free] -> t!free :: else skip fi;} 99 if 91 :: Producer_q?demand -> t?free; if 92 :: Producer_V.num_made 93 printf("TRANSITIONQ209130817257517©Producer 94 @2091306922803260Waiting_For_Demand 95 @2091307532288400Advertise 95 @209130817257519©demand\n"); 97 Producer_V.num_made=Producer_V.num_made+1; 95 goto Advertise 99 :: else -> goto Waiting_For_Demand_G M9 fi M1 :: 1 -> t?free; if 281 M2 :: Producer_V.num_made>=Producer_V.limited_ed -> M3 printf("TRANSITIONQ2091308172575146Producer M4 @2091306922803266Waiting_For_Demand M5 @209130753228840©Sorry_So1d_0ut MM @209130817257516@\n"); M7 goto Sorry_Sold_Out M5 :: else -> goto Waiting_For_Demand_G M9 fi Mo fi; 111/* State Sorry_Sold_Out */ M2Sorry_Sold_0ut: printf("in state Producer.Sorry_Sold-0ut\n"); M3 atomic {if :: !t?[free] -> t!free :: else skip fi;} M4 if M5 :: skip -> false M5 fi; M7/* State Advertise */ M5Advertisezprintf("in state Producer.Advertise\n"); M9 atomic {if :: !t?[free] -> t!free :: else skip fi;} M9 if 121 :: 1 -> t?free; M2 printf("TRANSITIONQ209134301741058@Producer M3 @2091306922803260Advertise 121 @209130817257519@Waiting-For_Demand M5 @209130753228840@\n"); M5 atomic{Consumer_supply_p1!Producer_V.num_made; M7 Consumer_qlsupply}; goto Waiting_For_Demand M5 fi; M9exit: skip no} 282 131 I32 M3proctype Consumer() I34 { 135 mtype m; M5int dummy; M7/* Init state */ M5/* Initial actions / messages */ M9 printf("TRANSITIONQ209130740318236©Consumer M9 @209130692280330QInitia1 M1 @2091307360583930Have_Money_Will_Spend M2 @209130736058394©modelstart\n"); M3 _SYSTEMCLASS__q!0K; M4 goto Have_Money_Will_Spend; M5/* State Have_Money_Will_Spend */ M5Have_Money_Will_Spend: M7 printf("in state Consumer.Have,Money_Will_Spend\n"); M5 atomic {if :: !t?[free] -> t!free :: else skip fi;} 5M if M9 :: 1 -> t?free; 151 printf("TRANSITIONQZOQ130748051488@Consumer M2 @209130692280330©Have_Money_Wil1_Spend M3 @209130736058394©Waiting_For_Supply M4 @209130747068447@\n"); M5 Producer_qldemand; goto Waiting_For_Supply M5 fi; M7/* State Waiting-For_Supply */ M5Waiting_For_Supply: printf("in state Consumer.Waiting_For_Supply\n"); M9 atomic {if :: !t?[free] -> t!free :: else skip fi;} 283 160 if M1 :: atomic{Consumer_q?supply -> M2 Consumer_supp1y_p1?Consumer_V.edition_num} -> t?free; M3 printf("TRANSITIONQ209130748051490©Consumer M4 @2091306922803306Waiting_For_Supply M5 @209130747068447QHave_Money_Will_Spend 55 @209130736058394qupp1y(edition_num)\n"); M7 goto Have_Money_Will_Spend M5 fi; M9exit: skip no} 171 173 M4/* This is the universal event dispatcher routine */ nsproctype event(mtype msg) n5{ n7 mtype type; n5 int pid; M9 M9 atomic { M1 do M2 :: evq??[eval(msg),pid] -> M3 evq??eva1(msg),pid; M4 evt!msg,pid; M5 do M5 :: if M7 :: evq??[type,eval(pid)] -> evq??type,eva1(pid) M5 :: else break; 284 189 fi 190 0d M1 2: else -> break 192 0d} 193 exit: Skip 194 } G.4 Both UML States and UML Transitions 1#define min(x,y) (xx:y) 2#define max(x,y) (x>y->x:y) 3chan evq=[10J of {mtype,int}; 4chan evt=[10] of {mtype,int}; 5chan wait=[10] of {int,mtype}; 5mtype={demand, 0K, supply}; 7chan _SYSTEMCLASS__q=[5] of {mtype}; stypedef Producer_T { 9 int limited-ed; 19 int num_made; ll } 12Producer_T Producer_V; 13chan Producer_q=[5] of {mtype}; 14typedef Consumer_T { 15 int edition_num; 15 } 17Consumer_T Consumer_V; 15chan Consumer_q=[5] of {mtype}; 19chan Consumer_supply_p1=[5] of {int}; 29chan t=[1] 0f {mtype}; 285 21mtype={free}; 22active proctype _SYSTEMCLASS_() 23{ 24mtype m; 2sint dummy; 25/* Init state */ 27/* Initial actions / messages */ 25 printf("TRANSITIONQ209130706632721@_SYSTEMCLASS- 29 @20913069228032461nitial 39 6209130704732174QCreate_Producer 31 @209130704732175©modelstart\n"); 32 goto Create_Producer; 33/* State Create_Producer */ 34Create-Producer: printf("in state _SYSTEMCLASS_.Create-Producer\n"); 35/* entry actions */ 35 atomic{ 37 printf(”STATE@_SYSTEMCLASS_@209130692280324 35 @Create_Producer@209130704732175\n");run 39 Producer(); 49 } 41 atomic {if :: !t?[freeJ -> t!free :: else skip fi;} 42 if 43 :: _SYSTEMCLASS__q?0K -> t?free; 44 printf("TRANSITIONQ209130706632723@_SYSTEMCLASS_ 45 @209130692280324©Create_Producer 45 0209130704732175@Create_Consumer 47 @209130704732176©0K\n"); 45 goto Create_Consumer 49 fi; 286 59/* State Create_Consumer */ 51Create_Consumer: printf("in state _SYSTEMCLASS_.Create_Consumer\n"); 52/* entry actions */ 53 atomic{ 54 printf("STATE@_SYSTEMCLASS_@209130692280324 55 @Create_Consumer@209130704732176\n");run 55 Consumer(); 57 } 55 atomic {if :: !t?[freeJ -> t!free :: else skip fi;} 59 if 59 :: _SYSTEMCLASS__q?OK -> t?free; 51 printf("TRANSITIONQZOQ1307066327256_SYSTEMCLASS_ 52 @209130692280324©Create_Consumer 53 @2091307047321766Done 54 @209130706632727QOK\n"); 55 goto Done 55 fi; 57/* State Done */ 55Done: printf("in state _SYSTEMCLASS_.Done\n"); 59/* entry actions */ 79 atomic{ n printf("STATE©_SYSTEMCLASS_@209130692280324 72 @DoneQ209130706632727\n"); 73 } 74 atomic {if :: !t?[freeJ -> t!free :: else skip fi;} 75 if 75 :: skip -> false 17 fi; 75 exit: skip 287 79} 59 m 52proctype ProducerC) 53{ 54mtype m; 55int dummy; 55 Producer_V.limited_ed = 5; 57/* Init state */ 55/* Initial actions / messages */ 59 printf("TRANSITIONQ209130753228837©Producer 99 @209130692280326@Initia1 91 ©209130753228839©Waiting_For_Demand 92 @209130753228840©mode1start\n"); 93 _SYSTEMCLASS__q!DK; 94 goto Waiting_For_Demand; 95/* State Waiting_For_Demand */ msWaiting_For_Demand: printf("in state Producer.Waiting_For_Demand\n"); 97/* entry actions */ 95 atomic{ 99 printf("STATEQProducerQ209130692280326 um @Waiting_For_Demand@209130753228840\n"); 191 } 1szaiting_For_Demand_G: “M atomic {if :: !t?[freeJ —> t!free :: else skip fi;} MM if 195 :: Producer_q?demand -> t?free; if MM :: Producer_V.num_made 197 printf("TRANSITIONQ209130817257517©Producer 288 108 1 09 110 111 112 113 11-1 115 116 117 118 119 120 121 122 123 124 @209130692280326©Waiting_For_Demand @209130753228840©Advertise @209130817257519©demand\n"); Producer_V.num_made=Producer_V.num_made+1; goto Advertise ': else -> goto Waiting_For_Demand_G fi 1 -> t?free; if Producer_V.num_made>=Producer_V.limited_ed -> printf("TRANSITIONQ2091308172575146Producer @209130692280326©Waiting_For_Demand @20913075322884OQSorry_So1d_0ut @209130817257516@\n"); goto Sorry_Sold-0ut ': else -> goto Waiting_For_Demand_G fi fi; 125/* State Sorry_Sold_Out */ 1msSorry_Sold_0ut: printf("in state Producer.Sorry-Sold_0ut\n"); 127/* entry actions */ 128 129 130 131 132 133 134 135 atomic{ printf("STATEQProducerQ209130692280326 ©Sorry_Sold_0ut@209130817257516\n"); } atomic {if :: !t?[free] -> t!free :: else skip fi;} if ': skip -> false fi; 1M5/* State Advertise 4/ 289 M7Advertise:printf("in state Producer.Advertise\n"); M5/* entry actions */ M9 atomic{ M9 printf("STATEQProducerQ209130692280326 141 ©Advertise©209130817257519\n"); M2 } M3 atomic {if :: !t?[freeJ -> t!free :: else skip fi;} M4 if M5 :: 1 -> t?free; M5 printf("TRANSITIONQ209134301741058©Producer M7 @209130692280326©Advertise M5 0209130817257519©Waiting_For_Demand 1M @209130753228840@\n"); M9 atomic{Consumer_supply_p1!Producer_V.num_made; 1m Consumer_qlsupply}; goto Waiting_For_Demand M2 fi; M3exit: skip m4} 155 156 M7proctype Consumer() 158 { 159 mtype m; 190 int dummy; 161/* Init state */ M2/* Initial actions / messages */ M3 printf("TRANSITIONQ209130740318236©Consumer M4 @209130692280330©Initia1 M5 @2091307360583936Have_Money_Will_Spend 290 M5 @209130736058394©mode1start\n"); M7 _SYSTEMCLASS__q!0K; M5 goto Have_Money_Will_Spend; M9/* State Have_Money_Will_Spend */ M9Have_Money_Will_Spend: 171 printf("in state Consumer.Have_Money_Will_Spend\n"); M2/* entry actions */ M3 atomic{ M4 printf("STATEQConsumerQ209130692280330 M5 @Have_Money_Wil1_Spend@209130736058394\n"); M5 1 M7 atomic {if :: !t?[free] -> t!free :: else skip fi;} M5 if M9 :: 1 -> t?free; M9 printf("TRANSITIONQZOQ130748051488©Consumer 1M @209130692280330©Have_Money_Will-Spend M2 @2091307360583946Waiting_For_Supply M3 @209130747068447©\n"); M4 Producer_qldemand; goto Waiting_For_Supply M5 fi; M5/* State Waiting_For_Supply */ M7Waiting_For_Supply: printf("in state Consumer.Waiting_For_Supp1y\n"); M5/* entry actions */ M9 atomic{ M9 printf("STATEQConsumer©209130692280330 M1 ©Waiting_For_Supply@209130747068447\n"); M2 } M3 atomic {if :: !t?[free] -> t!free :: else skip fi;} M4 if 291 Ms :: atomic{Consumer_q?supply —> Mo Consumer_supply_p1?Consumer_V.edition_num} —> t?free; M7 printf("TRANSITIONQ209130748051490©Consumer Ms @2091306922803300Waiting_For_Supply M9 @209130747068447©Have_Money_Will_Spend 2w) @209130736058394©supp1y(edition_num)\n"); 2m goto Have_Money_Will_Spend 202 f i ; zuzexit: skip W4} mm 206 207 ms/* This is the universal event dispatcher routine */ mgproctype event(mtype msg) m0{ m1 mtype type; m2 int pid; 2M m4 atomic { as do 2M :: evq??[eval(msg),pid] -> m7 evq??eva1(msg),pid; ms evt!msg,pid; mg do 220 : : if 2m :: evq??[type,eval(pid)] -> evq??type,eva1(pid) m2 :: else break; 223 fi 292 224 226 227 exit: 228 } od ': else -> break od} skip 293 Appendix H Produce'r- Consumer Spin Analysis Results This Appendix contains the Spin analysis results described in Chapter 8 for the Producer- Consumer model of Chapter 6. Figure H.1 gives the analysis results for the baseline Promela model, while Figures H.2, H.3, and H.4 give the analysis results for the breadcrumb options UML States, UML Transitions, and Both UML States and UML Transitions, respectively. Recall (Chapter 6, Section 6.3.4) that the “error” in each case is that a final demand message remains in the Producer queue. In Chapter 6 we did not refine the example further to handle this message. 294 pan: invalid endstate (at depth 183) pan: wrote pc_exp_none.pr.trail (Spin Version 3.3.3 -- 21 July 1999) Warning: Search not completed + Partial Order Reduction Full statespace search for: never-claim (none specified) assertion violations + acceptance cycles - (not selected) invalid endstates + State-vector 356 byte, depth reached 183, errors: 1 144 states, stored 3 states, matched 147 transitions (= stored+matched) 42 atomic steps hash conflicts: O (resolved) (max size 2‘18 states) 1.493 memory usage (Mbyte) Figure H.1: Spin analysis results for Producer- Consumer, baseline 295 pan: invalid endstate (at depth 210) pan: wrote pc_exp_states pr.trail (Spin Version 3.3.3 -- 21 July 1999) Warning: Search not completed + Partial Order Reduction Full statespace search for: never-claim (none specified) assertion violations + acceptance cycles - (not selected) invalid endstates + State-vector 356 byte, depth reached 210, errors: 1 169 states, stored 3 states, matched 172 transitions (= stored+matched) 44 atomic steps hash conflicts: 0 (resolved) (max size 2‘18 states) 1.493 memory usage (Mbyte) Figure H2: Spin analysis results for Producer-Consumer, breadcrumb option UML States 296 pan: invalid endstate (at depth 201) pan: wrote pc_exp_trans.pr.trail (Spin Version 3.3.3 -- 21 July 1999) Warning: Search not completed + Partial Order Reduction Full statespace search for: never-claim - (none specified) assertion violations + acceptance cycles - (not selected) invalid endstates + State-vector 356 byte, depth reached 201, errors: 1 162 states, stored 3 states, matched 165 transitions (= stored+matched) 42 atomic steps hash conflicts: O (resolved) (max size 2‘18 states) 1.493 memory usage (Mbyte) Figure H.3: Spin analysis results for Producer- Consumer, breadcrumb option UML Transitions 297 pan: invalid endstate (at depth 228) pan: wrote pc_exp_both.pr.trail (Spin Version 3.3.3 -- 21 July 1999) Warning: Search not completed + Partial Order Reduction Full statespace search for: never-claim - (none specified) assertion violations + acceptance cycles - (not selected) invalid endstates + State-vector 356 byte, depth reached 228, errors: 1 187 states, stored 3 states, matched 190 transitions (= stored+matched) 44 atomic steps hash conflicts: O (resolved) (max size 2‘18 states) 1.493 memory usage (Mbyte) Figure H.4: Spin analysis results for Producer- Consumer, breadcrumb option Both UML States and UML Transitions 298 Appendix I Original Fault Handler Requirements Pattern This Appendix contains Konrad et al.’s original Fault Handler requirements pat- tern [3, 4] prior to refinements discussed in Chapter 9. 1.1 Fault Handler: Behavioral Pattern Intent: Specify a centralized fault handler for an embedded system. Motivation: Fault handling is essential for embedded systems. Embedded systems frequently need to determine what responses are necessary to recover from errors. Consider a flight control system in an airplane, where the system should never shut down completely in response to an error. The system has to decide if it should perform a partial shutdown and offer basic functionality, or if the error is no threat to system safety and logging is sufficient. This fault handler must offer the possibility for other devices to read the error log. But it should also have access to a user interface to 299 signal that errors have occurred. An important function of the fault handler is to send the system into different safety states depending on the severity of the error. These safety states have to be implemented in the computing component, such as the operation for performing an emergency stop. If an error is reported to the fault handler justifying this action, then the fault handler will activate this state. Therefore, the fault handler acts as a centralized coordinator for safety monitoring and, hence, control of system recovery. The following inputs are usually captured [37]: o Timeout messages by watchdogs, examiners, or monitors. 0 Assertions of software errors. 0 Built-in-tests (BITS) that run on a periodic or continuous basis. The centralized safety control facilitates the verification and validation of the safety measures and eases the reuse of the fault handle r in different systems. Figure 1.1 gives the use—case diagram for the Fault Handler Pattern, with the major goals being to detect and to handle faults. Use-Case: System running. Actors: None Description: This use-case represents the system when it is functioning. Includes: Handle faults, Interact with user 300 cfloEcoo... 3.23 “850 AAowEoEvv AAUcm§mivv omocoflo ouos. 2mm 5 3-3“& \ \ mica: AAocoiwvv \ ’ AAmonEvv \ \ 9:22 .8: 5E low: AAoquEvY £553 692:. Bancaom £296 voouonEw .. Eon.ommoémni-do_ocmrzama P. L Figure 1.1: UML use-case diagram for the Fault Handler Pattern 301 Use—Case: Use in safe mode. Actors: User Description: Special case of the use-case System running. System offers basic functionality due to errors that have occurred. The exact level of function- ality is system-dependent. Includes: - Use-Case: Interact with user. Actors: User Description: Read user settings and activate indicators. Includes: - Use-Case: Handle faults. Actors: None Description: Initiate corrective actions if needed. Includes: Detect faults. 302 Use-Case: Diagnose faults. Actors: Technician Description: Special case of the use-case Handle faults. The system offers ex- tended diagnostic functions instead of handling faults to identify the source of the fault(s). Includes: - Use-Case: Detect faults. Actors: None Description: The system offers fault detection functionality. Includes: - Applicability: The Fault Handler Pattern is applicable 0 in embedded systems where fault handling is to be centralized. Structure: The UML class diagram of the Fault Handler Pattern can be seen in Figure 1.2. The FaultHandler sends messages to the UserInterface to activate warning levels and sends the ComputingComponent into different safety states. For every safety state defined in the requirements, an operation in the ComputingComponent is needed. The safety states are listed in the Behavior field. The FaultHandler also receives error messages from Watchdogs, Examiners, and Monitors. The Device class represents possible devices in the system that also send error messages to the FaultHandler. 303 Depending on the safety measures and policies defined, the FaultHandler decides what action to take, for example, such as activating a FailSafeDevice. controls sends 1 ComputingComponent FaultHandler "mes” UserInterface 1 69 1 0 A1 t°Q° 3 '5 c t- 22 0 ° ‘ 0.: °--' monitors 1 backs up Watchdog! o..- o..- . FailSafeDevIce Examiner 1m Device ‘ a 8 a 1 a g 8 C O a o..* 0... Monitor ‘— Figure 1.2: Structural Diagram for the Fault Handler Pattern Behavior: Figure I3 shows the state diagram of the ComputingComponent of the Fault Han- dler Pattern. The state diagram shows which states are possible and what messages activate them. Not all of the states are needed in every system. For example, ABS systems generally do not have partial shutdown states because the system constraints require that an inactive system should not affect the basic functionality of the brakes. Therefore, an emergency stop where the ABS system cuts power immediately is suf- ficient. These states are defined for the class ComputingComponent; when an error occurs, the FaultHandler decides which state is appropriate and sends the respective message to the ComputingComponent to activate the corresponding state if needed. 304 The FaultHandler also activates the UserInterface to notify the system user of the cur- rent system state. The definitions for the possible system states are as follows [37]: 0 Normal Behavior: This state captures the system when no errors have oc- curred and it is functioning normally. 0 Manual / External: In this state, the system is controlled by an external entity, such as a diagnostic device. 0 Production Stop: This state is useful, for example, when a human enters a hazardous area. The system should be able to complete its current task and secure the environn’ient, but it should shutdown as soon as possible. 0 Protection Stop: Ceases operation immediately, but does not turn off power. This state is appropriate, for example, when a machine needs to be stopped, but a device should continue to operate to avoid hazardous situations. For example, a cooling device should remain working even in case of a system malfunction. 0 Partial Shutdown: The system only offers basic functionality; for example, medical devices may remain in a monitoring state. 0 Hold: No functionality is provided in this state, but safety actions are taken; for example, a rocket self-destructs in the case of abnormal functions. There is no outgoing transition from this state; a system can only be reactivated by a complete restart. o Initialize: In this state, the system initializes itself. 0 Power Off: The system might be connected to a power supply in this state, but is not yet activated. For example, a television set can operate in a standby mode. 305 Furthermore, an emergency stop can be performed by the system. This stop state is not modeled as a separate state because this action takes the system to the PowerOff state immediately. Participants: FaultHandler: Fault handler of the system. Contains safety measures and poli- cies. o ComputingComponent: Central computing component of the system. 0 UserInterface: Class offering functionality to notify the user about errors. 0 Device: Component representative for a number of possible devices in the sys- tem. o Watchdog/ Examiner: Watchdog or examiner in the system. 0 Monitor: Possible monitor monitoring the Device. o FailSafeDevice: Possible backup component for the Device. Collaborations: o The FaultHandler receives error messages and stores those messages in an error log. Furthermore, the FaultHandler decides, depending on the safety measures and policies, if a fail-safe state in the ComputingComponent should be entered, or whether the user interface or recovery device should be activated. 0 Watchdog, Examiner, and/or Monitor monitor the device and report violations to the Fault Handler. o FailSafeDevice is activated to recover from faults. 306 \CCmflgUu—fim l \C \: \CCEOHE \ 8.33 8333.33: \CCVHOMO’OA :uuougm \SCUOIQK _i Eofisu oufigéou \ 2360000:- 83.31332 053E:— \ S R among—33m 44 \ _I" . x S A :lauuuugvuanm j \C CEUSAM _ A .uo-ox cigszm .2th \CCOaOI I. 839.5929 532.3 .2502 \CCHS—nl! T 22.035534 i1 Raw 5.8295 gin—5:3 2036003“. new 8.625... \ S A Vang—gunfim \ C Sauna-06033 .2200 35353352 Figure 1.3: UML state diagram of the ComputingComponent in the Fault Handler Pattern 307 o The UserInterface gets activated by the FaultHandler. Consequences: 1. Required safety states have to be implemented in the ComputingComponent. 2. Only one fault handler should exist in the system and should handle all error messages to avoid inconsistent handling of faults [37]. 3. The fault handler is one of the critical elements for system safety. Therefore, during the development process of this component, techniques should be used that result in a high assurance of the software component, such as formal meth- ods and thorough testing. 4. Hardware and software redundancies exist in the system, thus meaning higher system costs. 5. Overall safety of the system can significantly be improved by the centralized fault handling component. Constraints: 0 Absence Pattern: If system initialization fails, then the system should remain in a powered-off state. Therefore, the system should never be in a state where the initialization failed and the system power is on. El(! (‘ ‘Initialization failed’ ’ && “System power on’ ’)) 0 Response Pattern: When an error message is sent to the fault handler, it should process the er- ror and, depending on the error classification, perform the predefined recovery 308 action as a result of the error. This action can range from “Do nothing” to “Perform emergency shutdown of the system”. Cl( ‘ ‘Error reported to fault handler’ ’ —> O(“Start defined recovery action”)) 0 Response Pattern: When an error message is sent, it should be stored in an error log for system diagnosis purposes. Cl(‘ ‘Error reported to fault handler” —> O(“Store error in error log”)) 0 Response Pattern: If an error message is sent to the fault handler, then it should activate the appropriate user interface warning level if required. D(‘ ‘Error reported to fault handler’ ’ —+ O(“Activate appropriate user interface warning level”)) 0 Response Pattern: If some device, such as a diagnostic device, requests the current error list, then the error list should be sent to the device. CK ‘ ‘Error list requested from fault handler’ ’ —> O(“Return list of errors in error log”)) Design Patterns: 0 Singleton Design Pattern [83]: Assure that only one fault handler exists in the system. 309 0 Strategy Design Pattern [83]: Encapsulate algorithms for the safety states and make them interchangeable. Also Known As: To be determined. Known Uses: To be determined. Related Requirements Patterns: 0 Controller Decompose Requirements Pattern: This requirements pattern describes how the fault handler relates to other com- ponents in a system. 0 User Interface Requirements Pattern: This pattern can be used for the user interface to signal a user the current system state. 310 BIBLIOGRAPHY 311 Bibliography [1] Sascha Konrad, Betty H.C. Cheng, and Laura A. Campbell. Object-analysis patterns for embedded systems. Transactions on Software Engineering, 2004. Submitted for publication. [2] Sascha Konrad and Betty H.C. Cheng. Requirements patterns for embedded systems. Technical Report MSU-CSE—02-4, Computer Science and Engineering, Michigan State University, East Lansing, Michigan, February 2002. [3] Sascha Konrad. Identification, classification, and application of requirements patterns. Technical Report MSU-CSE—02—6, Computer Science and Engineering, Michigan State University, East Lansing, Michigan, February 2002. [4] Sascha Konrad and Betty H.C. Cheng. Requirements patterns for embedded systems. In Proceedings of the IEEE Joint International Conference on He- quirements Engineering (REOQ), Essen, Germany, September 2002. [5] E. Allen Emerson and Joseph Y. Halpern. “Sometimes” and “Not Never” re- visited: On branching versus linear time temporal logic. Journal of the ACM, 33(1):151—178, Jan 1986. [6] John Rushby. Critical system properties: Survey and taxonomy. Reliability Engineering and System Safety, 43(2), 1994. [7] Roger S. Pressman. Software Engineering: A Practitioner’s Approach. McGraw- Hill, 4‘“ edition, 1997. [8] Sue Conger. The New Software Engineering. The Wadsworth Series in Man- agement Information Systems. Wadsworth Publishing Company, 1994. [9] Robyn R. Lutz. Targeting safety-related errors during software requirements analysis. In Proceedings of the First ACM Symposium on the Foundations of Software Engineering, Los Angeles, CA, December 1993. [10] Jeannette M. Wing. A Specifier’s Introduction to Formal Methods. IEEE Computer, 23(9):8—-24, September 1990. [11] C. Michael Holloway and Ricky W. Butler. Impediments to industrial use of formal methods. IEEE Computer, 29(4):25—26, April 1996. 312 [12] Peter Coad and Edward Yourdon. Object-Oriented Analysis. Yourdon Press, Prentice Hall, Englewood, New Jersey, 1990. [13] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. Designing Object- Oriented Software. Prentice Hall, Englewood, New Jersey, 1990. [14] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen. Object-Oriented Modeling and Design. Prentice-Hall, 1991. [15] Ivar Jacobson. Object-Oriented Software Engineering: A Use Case Driven Ap- proach. Addison-Wesley, 1994. [16] Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1999. [17] James Rumbaugh, Ivar Jacobson, and Grady Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1999. [18] Object Management Group (OMG). OMG Unified Modeling Language (UML) 1.3 Specification. Technical report, OMG, March 2000. www.omg.org/cgi-bin/ doc?formal/OO-03-01. [19] Rational. Rational Rose. www.rational.com. [20] I-logix. Rhapsody. www.ilogix.com. [21] Christian N entwich, Wolfgang Emmerich, and Anthony F inkelstein. Static con- sistency checking for distributed specifications. In Proceedings of the 16‘“ IEEE International Conference on Automated Software Engineering (ASEUI), San Diego, November 2001. [22] Fiona Hayes and Derek Coleman. Coherent models for ob ject—oriented analysis. In Proceedings of OOPSLA ’91, pages 171—183, 1991. [23] Lesley T. Semmens, Robert B. France, and Thomas W.G. Docker. Integrated structured analysis and formal specification techniques. The Computer Journal, 35(6):600—610, 1992. [24] Robert H. Bourdeau and Betty H.C. Cheng. A formal semantics of object models. IEEE Transactions on Software Engineering, 21(10):799—821, October 1995. [25] Ana Maria Dinis Moreira and Robert G. Clark. Adding rigour to ob ject-oriented analysis. Software Engineering Journal, 11(5):270—280, 1996. [26] Malcolm Shroff and Robert B. France. Towards a Formalization of UML Class Structures in Z. In Proceedings of the 213t Annual International Computer Software and Applications Conference (COMPSAC97), pages 646—651. IEEE Computer Society, Los Alamitos, CA, August 1997. 313 [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] Yile Enoch Wang. Integrating Informal and Formal Approaches to Object- Oriented Analysis and Design. PhD thesis, Michigan State University, East Lansing, Michigan, March 1998. Diego Latella, Istvan Majzik, and Mieke Massink. Towards a formal opera- tional semantics of UML statechart diagrams. In Proceedings of the 3'“ In- ternational Conference on Formal Methods for Open Object-Based Distributed Systems (FMOODS‘QQ), IFIP TC6/W06.1, Florence, Italy, February 1999. Kluwer. Prasanta Bose. Automated translation of UML models of architecture for ver- ification and simulation using SPIN. In Proceedings of the 14‘“ IEEE Interna- tional Conference on Automated Software Engineering (ASEQQ), Cocoa Beach, FL, October 1999. William E. McUmber and Betty H.C. Cheng. UML-based analysis of embedded systems using a mapping to VHDL. In Proceedings of the 4‘“ IEEE Interna- tional Symposium on High Assurance Systems Engineering {HASEQQ}. Special Theme: Integration Issues in High Assurance Embedded Systems, Washington, DC, November 1999. William E. McUmber. A Generic Framework for Formalizing Object-Oriented Modeling Notations for Embedded Systems Development. PhD thesis, Michigan State University, East Lansing, Michigan, August 2000. Rik Eshuis and Roel Wieringa. Requirements-level semantics for UML stat- echarts. In SF. Smith and CL. Talcott, editors, Formal Methods for Open Object-Based Distributed Systems (FMOODS) IV, pages 121—140. Kluwer Aca- demic Publishers, October 2000. William E. McUmber and Betty H.C. Cheng. A general framework for for- malizing UML with formal languages. In Proceedings of IEEE International Conference on Software Engineering (ICSEUI), Toronto, Canada, May 2001. Daniel Jackson. Alloy: A lightweight object modelling notation. ACM Trans- actions on Software Engineering and Methodology, 11(2):256—290, April 2002. Betty H.C. Cheng, Laura A. Campbell, Min Deng, and R.E.K. Stirewalt. En- abling validation of UML formalizations. Technical Report MSU-CSE-02-25, Department of Computer Science and Engineering, Michigan State University, East Lansing, Michigan, September 2002. Eduardo B. Fernandez and Xiaohong Yuan. Semantic Analysis Patterns. In Pro- ceeding of the 19117 International Conference on Conceptual Modeling (ERZOUO), pages 183—195, Salt Lake City, UT, October 2000. Bruce Powell Douglass. Doing Hard Time: Developing Real- Time Systems with UML, Objects, Frameworks, and Patterns. Addison—Wesley, 1999. 314 [38] Jack Ganssle. Navigating through new development environments. Embedded [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] Systems Programming Magazine, 12(5), May 1999. Wayne Wolf. Computers as Components: Principles of Embedded Computing System Design. Morgan Kaufmann, Academic Press, 2001. Laura A. Campbell, Betty H.C. Cheng, William E. McUmber, and R.E.K. Stirewalt. Automatically detecting and visualizing errors in UML diagrams. Requirements Engineering Journal, 7(4):264—287, December 2002. Sascha Konrad, Laura A. Campbell, Betty H.C. Cheng, and Min Deng. A requirements pattern-driven approach to specify systems and check properties. In Proceedings of the 10"“ International SPIN Workshop of Model Checking of Software (SPIN 2005’), Oregon, May 2003. Workshop co-located with ICSE03. Sascha Konrad, Laura A. Campbell, Betty H.C. Cheng, and Min Deng. A re- quirements pattern-driven approach to specify systems and check properties. Technical Report MSU-CSE—02-28, Department of Computer Science and En- gineering, Michigan State University, East Lansing, Michigan, December 2002. Full-length technical report. Condensed workshop version of this report appears in Proceedings of the 10‘“ International SPIN Workshop of Model Checking of Software ( SPIN 2003), co-located with ICSE03. Matthew B. Dwyer, George S. Avrunin, and James C. Corbett. Patterns in property specifications for finite-state verification. In Proceedings of the 213‘ International Conference on Software Engineering (ICSEQQ), May 1999. Laura A. Campbell. Enabling automated analysis of object-oriented models. Michigan State University Department of Computer Science and Engineering Poster Workshop, April 1999. Betty H.C. Cheng, Laura A. Campbell, and Enoch Y. Wang. Enabling auto- mated analysis through the formalization of ob ject-oriented modeling diagrams. In Proceedings of the IEEE International Conference on Dependable Systems and Networks (FTCS—SU and DCCA-8), New York, NY, June 2000. Laura A. Campbell and Betty H.C. Cheng. Object-oriented modeling and au- tomated analysis of a telemedicine application. In Proceedings of the IEEE 1n- ternational Workshop on Software Specification and Design (IWSSD-IO), San Diego, CA, November 2000. Laura A. Campbell. MINERVA: Metamodel—based intuitive editors with reports and visualization of analysis. Michigan State University Department of Com- puter Science and Engineering Poster Workshop, March 2001. One of 4 Best Overall Posters from a pool of 30 or more posters. William E. McUmber and Laura A. Campbell. Hydra: A general framework for formalizing UML with formal language for embedded systems. Michigan State 315 [49] [54] [55] [56] l 7] University Department of Computer Science and Engineering Poster Workshop, March 2001. Laura A. Campbell and William E. McUmber. A framework for detecting and visualizing structural and behavioral errors of UML diagrams. Michigan State University Department of Computer Science and Engineering Poster Workshop, March 2001. Laura A. Campbell. Visualization and interpretation of analysis results within the context of formalized UML diagrams. In Proceedings of Doctoral Sympo— sium for IEEE International Conference on Software Engineering (ICSEOI), Toronto, Canada, May 2001. Abstract for Doctoral Symposium. Laura A. Campbell. Structural and behavioral analysis of formalized UML diagrams. In Proceedings of Doctoral Symposium for 5‘” IEEE International Symposium on Requirements Engineering (REOI), Toronto, Canada, August 2001. Abstract for Doctoral Symposium. Betty H.C. Cheng and Laura A. Campbell. Integrating informal and formal approaches to requirements modeling and analysis. In Proceedings of Poster Workshop for IEEE Requirements Engineering (REOI), Toronto, Canada, Au- gust 2001. Abstract for Poster Workshop. Sascha Konrad, Laura A. Campbell, and Betty H.C. Cheng. Adding formal specifications to requirements patterns. In Proceedings of the IEEE Work— shop on Requirements for High Assurance Systems (RHASOQ), Essen, Germany, September 2002. Workshop affiliated with RE02. Sascha Konrad, Laura A. Campbell, and Betty H.C. Cheng. Automated anal- ysis of timing information in UML diagrams. In Proceedings of the 19th IEEE International Conference on Automated Software Engineering (ASE04), Linz, Austria, September 2004. Short paper. To appear. Sascha Konrad, Laura A. Campbell, and Betty H.C. Cheng. Automated analysis of timing information in UML diagrams. Technical Report MSU-CSE-03-17, Computer Science and Engineering, Michigan State University, East Lansing, Michigan, Revised 2004. Short paper version to appear in the Proceedings of the 19‘” IEEE International Conference on Automated Software Engineering (ASEOt). Laura A. Campbell. A modeling / analysis framework and process for validating embedded systems requirements with verification techniques. Michigan State University Department of Computer Science and Engineering Poster Workshop, May 2004. Anish Arora and Sandeep Kulkarni. Detectors and correctors: A theory of fault-tolerance. In Proceedings of the International Conference on Distributed Computing Systems (ICDCS), pages 436—443, May 1998. 316 [58] Enoch Y. Wang, Heather A. Richter, and Betty H.C. Cheng. Formalizing and integrating the dynamic model within OMT. In Proceedings of IEEE Interna- tional Conference on Software Engineering (ICSEQ’I), Boston, MA, May 1997. [59] Enoch Y. Wang and Betty H.C. Cheng. Formalizing and integrating the func- tional model into object-oriented design. In Proceedings of International Con- ference on Software Engineering. and Knowledge Engineering, June 1998. Nom- inated for Best Paper. [60] Enoch Y. Wang and Betty H.C. Cheng. A rigorous object-oriented design process. In Proceedings of International Conference on Software Process, Naperville, Illinois, June 1998. [61] Tommaso Bolognesi and Ed Brinksma. Introduction to the-ISO specification language LOTOS. Computer Networks and ISDN Systems, 14(1):25—59, 1987. [62] David Hare]. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8, 1987. [63] National Institute of Standards. Dictionary of algorithms and data structures. www.nist.gov/dads/. [64] Hartmut Ehrig and Bernd Mahr. Fundamentals of Algebraic Specification 1: Equations and Initial Semantics. ETACS, Monographs on Theoretical Com— puter Science. Springer Verlag, 1985. [65] Ian Sommerville. Software Engineering. Addison-Wesley, 1996. [66] Santiago Pavon and Martin Llamas. The testing functionalities of LOLA. In Juan Quemada, Jose A. Manas, and Enrique Vazquez, editors, Formal De- scription Techniques, volume III, pages 559—562. IFIP, Elsevier Science B.V. (North-Holland), 1991. [67] Jean-Claude Fernandez, Hubert Garavel, Alain Kerbrat, Radu Mateescu, Lau- rent Mounier, and Mihaela Sighireanu. CADP (CESAR/ALDEBARAN Devel- opment Package): A protocol validation and verification toolbox. In Proceed- ings of the 8‘“ Conference on Computer-Aided Verification (New Brunswick, New Jersey, USA), volume 1102 of LNCS, pages 437—440, August 1996. www.inrialpes.fr/vasy/cadp.html. [68] IEEE. IEEE Standard VHDL Language Reference Manual, June 1994. ANSI/IEEE Std 1076-1993. [69] Gerald J. Holzmann. Design and Validation of Computer Protocols. Prentice- Hall, 1991. [70] Edmund M. Clarke, Orna Grumberg, and Doron Peled. Model Checking. MIT Press, 1999. 317 [71] [72] [73] [74] [75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] B. Cheng, P. Haley, G. Gannod, J. Kusler, S. Schafer, J. Sharnowski, and E. Wang. A distributed, ob ject-oriented multimedia environmental information system: A development document. MSU Technical Report CPS-94-60, Michigan State University, East Lansing, Michigan, November 1994. The teleservices and remote medical care system (TRMCS). www.ics.uci. edu/iwssd/case-study.pdf,2000. Robin Milner. A calculus of communication systems. In Lecture Notes in Computer Science, volume 92. Springer Verlag, 1980. Jean-Claude Fernandez and Laurent Mounier. Verifying bisimulations “on the fly”. In Juan Quemada, José Manas, and Enrique Vazquez, editors, Proceed- ings of the 3'“ International Conference on Formal Description Techniques FORTE ’90 (Madrid, Spain). North-Holland, November 1990. Kenneth L. McMillan. Symbolic Model Checking: An Approach to the State Explosion Problem. Kluwer Academic Publishers, 1993. Tom Sato and Brian V. Smith. Xfig user manual, version 3.2.3c. file: /soft/ sparc/xclients/lib/Xl1/xfig/html/index.html, July 2000. Anthony Torre. Project specifications for adaptive cruise control system, 2001. http://www.cse.msu.edu/"cse470/Public/F01/Projects/. Willie D. Jones. Keeping cars from crashing. IEEE Spectrum, September 2001. Wilhelm Grimm and Jacob Grimm. Hansel and Gretel. Penguin USA, 1986. Bee Software Foundation. GNU Compiler Collection, 2004. gcc.gnu.org. John McLean and Constance Heitmeyer. High assurance computer systems: A research agenda. In America in the Age of Information, National Science and Technology Council on Information and Communication Forum, Bethesda, MD, 1995. Peter Alan Lee and Thomas Anderson. Fault Tolerance — Principles and Prac- tice, volume 3 of Dependable Computing and Fault- Tolerant Systems. Springer- Verlag/Wien, New York, second, revised edition, 1990. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Pat- terns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. Anthony Torre. Project specifications for diesel filter system, 2000. www. cse. msu.edu/"Cse470/Public/FOO/Projects/air-filter.html. Anthony Torre. Project specifications for integrated starter/ generator, 1999. www.cse.msu.edu/“cse470/F99/Projects/. 318 [86] Jeremy Bowers. Project specifications for anti-lock brake system, 2001. www. cse.msu.edu/"cse470/Public/FOl/Projects/ABS/. [87] Honeywell Corporation. DOME Guide, version 5.2.1 edition, 1999. www.htc. honeywell.com/dome. [88] Honeywell. DOME. www.htc.honeywell.com/dome. [89] MetaCase Consulting. Domain-specific modeling: 10 times faster than UML. White paper, MetaCase Consulting, January 2001. [90] Tigris. ArgoUML features. argouml.tigris.org/features.html, 2001. [91] Corin Gurr and Perdita Stevens. A cognitively informed approach to describing product lines in UML. Technical Report (unpublished), University of Edin- burgh, Edinburgh, Scotland, 1999. [92] Matthias Riebisch, Kai Bollert, Detlef Streitferdt, and Bogdan Franczyk. Ex- tending the UML to model system families. In Proceedings of the Fifth Interna- tional Conference on Integrated Design and Process Technology (IDPT) 2000, Dallas, TX, June 2000. Society for Design and Process Science. [93] Nima Kaveh and Wolfgang Emmerich. Deadlock detection in distributed object systems. In Proceedings of the 8‘“ European Software Engineering Conference (ESEC ’01), Vienna, Austria, September 2001. [94] Mario Dal Cin. Extending UML towards a useful OO-language for modeling dependability features. Technical Report (unpublished), Friedrich-Alexander Universitat de Erlangen-Niirnberg, Germany, 2003. [95] Grant Martin. UML for embedded systems specification and design: Motivation and overview. In Proceedings of the Conference on Design, Automation, and Test in Europe. IEEE Computer Society, 2002. [96] Joao M. Fernandes, Ricardo J. Machado, and Henrique D. Santos. Modeling industrial embedded systems with UML. In Proceedings of the Eighth Interna- tional Workshop on Hardware/Software Codesign, San Diego, CA, 2000. ACM Press. [97] Object Management Group (OMG). UML 2.0 working draft. www.um1.org, August 2004. [98] Rational. Using UML for modeling complex real-time systems. www.ibm.com/developerworks/rational/library/content/OBJuly/1000/ 1155/11%55_umlmodeling.pdf, March 1998. [99] Rational/IBM. Mapping object to data models with the UML. www3. software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/ 2003/ti185.pdf,2003. 319 [100] [101] [102] [103] [104] [105] [106] [107} [108] [109] [110] [111] [112] Rational. Modeling web application architectures with UML. www3. software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/ 2003/°/.webapps .pdf, June 1999. Rational. Effective business modeling with UML: Describing business use cases and realizations. www.ibm.com/developerworks/rational/library/ 905.html, June 2003. Object Management Group (OMG). UML profile for schedulability, perfor- mance and time. www.omg.org/cgi-bin/doc?ptc/2002-03-O2, 2002. Object Management Group (OMG). UML profile for CORBA. www.omg.org/ technology/documents/formal/profile_corba.html, April 2002. Bruce Powell Douglass. Real- Time Design Patterns: Robust Scalable Architec- ture for Real- Time Systems. Addison-Wesley, 2003. Martin Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997. Mary Shaw. Some patterns for software architectures. In John M. Vlissides, James O. Coplien, and Norman L. Kerth, editors, Pattern Languages of Program Design, volume 2, pages 255—269. Addison-Wesley Longman Publishing Co., Inc., 1996. Wolfgang Keller. Object / relational access layers - a roadmap, missing links and more patterns. In Proceedings of EuroPLoP 1998, Bad Irsee, Germany, July 1998. Michael Adams, James Coplien, Robert Gamoke, Robert Hanmer, Pfed Keeve, and Keith Nicodemus. Fault-Tolerant Telecommunication System Patterns. In Proceedings of the 2nd Conference on Pattern Language of Programs, Mon- ticello, Illinois, September 1995. http://www.bell-labs.com/user/cope/ Patterns/PLoP95_telecom.html. Proceedings of the Patterns in Distributed Real- Time and Embedded Systems Workshop as part of the Conference on Object- Oriented Programming, Systems, Languages, and Applications, Tampa, FL, October 2001. Proceedings of the 9‘“ Conference on Pattern Language of Programs, Monticello, IL, September 2002. Proceedings of the Patterns in Distributed Real- Time and Embedded Systems Workshop as part of the Conference on Object- Oriented Programming, Systems, Languages, and Applications, Seattle, WA, November 2002. Antonio Rito Silva. Dasco project — development of distributed applications with separation of concerns, 2000. http://www.esw. inesc .pt/"ars/dasco/. 320 [113] Doug Lea. Design Patterns for Avionics Control Systems. Technical Report ADAGE-OSW-94—01, DSSA Adage Project, 1994. [114] EventHelix.com. Realtime mantra, 2004. http://www.eventhelix.com/ RealtimeMantra. [115] Sascha Konrad, Betty H. C. Cheng, Laura A. Campbell, and Ronald Wasser- mann. Using security patterns to model and analyze security requirements. In Proceedings of the Requirements for High Assurance Systems Workshop (RHASOS) as part of the IEEE Joint International Conference on Requirements Engineering (RE03), Monterey, CA, September 2002. [116] Eduardo Fernandez. Good analysis as the basis for good design and implementa- tion. Technical Report TR-CSE—97—45, Florida Atlantic University, September 1997. Presented at OOPSLA’97. [117] Peter Coad, David North, and Mark Mayfield. Object Models (2nd ed.) Strate- gies, Patterns, and Applications. Yourdon Press, 1997. [118] Andreas Geyer—Schulz and Michael Hahsler. Software engineering with analysis patterns, 2001. http: //wwwai .wu-wien. ac. at/"hahsler/research/virlib_ working2001/virlib/Z. [119] Fonda Daniels, Kalhee Kim, and Mladen A. Vouk. The reliable hybrid pattern: A generalized software fault tolerant design pattern. In Proceedings of Pattern Languages of Programming, 1997. [120] Lucianne Lamour Ferreira and Cecilia Mary Fischer Rubira. Reflective design patterns to implement fault tolerance. In Workshop on Reflective Programming in C++ and Java, OOPSLA ’98, Vancouver, BC, Canada, October 1998. [121] World Wide Web Consortium (W3C). Extensible markup language (XML) 1.0 (second ed). www.w3.org/TR/REC-xml, October 2000. [122] Francis Schneider, Steve Easterbrook, John Callahan, and Gerard Holzmann. Validating requirements for fault tolerant systems using model checking. In Proceedings of the 3'" International Conference on Requirements Engineering, pages 4—13, Colorado Springs, Colorado, April 1998. [123] Gerald Luettgen and Victor Carreno. Analyzing mode confusion via model checking. In Proceedings of the 6"" International SPIN Workshop on Practical Aspects of Model Checking (SPIN99), Toulouse, France, September 1999. [124] Alessandro Cimatti, Fausto Giunchiglia, Giorgio Mongardi, Dario Romano, Fer- nando Torielli, and Paolo Traverso. Model checking safety-critical software with SPIN: An application to a railway interlocking system. In Proceedings of the 17‘” International Conference on Computing Safety, Reliability, and Security, pages 284—295, Heidelberg, October 1998. 321 [125] Edsger W. Dijkstra. Guarded commands, nondeterminacy and formal deriva- tion of programs. Communications of the ACM, 18(8):453—457, August 1975. [126] GAR. Hoare. Communicating sequential processes. Communications of the ACM, 21(8):666-677, August 1978. [127] Johan Lilius and Ivan Porres Paltor. vUML: a tool for verifying UML models. In Proceedings of the IEEE International Conference on Automated Software Engineering (ASEQQ), Cocoa Beach, FL, October 1999. [128] Stefan Leue and Gerard Holzmann. v-Promela: A visual, object~oriented lan- guage for SPIN. In Proceedings of the 2"“ IEEE International Symposium on Object-Oriented Real-Time Distributed Computing. IEEE Computer Soci- ety Press, May 1999. [129] ARTiSAN Software. Real-time Studio. www.artisansw.com. [130] Telelogic. TAU Generation2. www.telelogic.com. [131] Jozef Hooman. Towards formal support for UML—based development of embed- ded systems. In Proceedings of the 3'" Workshop on Embedded Systems (Pro- gram for Research on Embedded Systems and Software: PROGRESS 2002), pages 71—76. Technology Foundation STW, 2002. [132] Constance L. Heitmeyer, James Kirby, Bruce G. Labaw, and Ramesh Bharad- waj. SCR*: A toolset for specifying and analyzing software requirements. In Proceedings of the 10'“ International Computer Aided Verification Conference, Vancouver, Canada, June 1998. [133] Jeffery M. Thompson, Mats PE. Heimdahl, and Steven P. Miller. Specification- based prototyping for embedded systems. In Proceedings of the Seventh ACM SI GSOF T Symposium on the Foundations of Software Engineering, Toulouse, fiance, September 1999. [134] Nancy G. Leveson, Mats P.E. Heimdahl, Holly Hildreth, and Jon D. Reese. Requirements specification for process-control systems. IEEE Transactions on Software Engineering, 20(9):684—707, September 1994. [135] Jerry Krasner. UML reduces embedded design costs and speed time-to-market. www . embeddedstar . com/ press/ content/ 2004/ 4/ embedded 14153 . html, April 2004. [136] Werner Damm and David Harel. Live sequence charts (LSCS): Breathing life into message sequence charts. Formal Methods in System Design, 19(1):45—80, 2001. [137] Rational Software Corporation, 2800 San Tomas Expressway, Santa Clara, CA 95051-0951. Object Constraint Language Specification, 1.1 edition, September 1997. 322 [138] [139] [140] [141] [142] [143] [144] [145] [146] [147] [148] [149] Angelo Gargantini and Elvinia Riccobene. Automatic model driven animation of SCR specifications. In Proceedings of Fundamental Approaches to Software Engineering (FASE 2003), Warsaw, Poland, April 2003. Steven P. Miller. Specifying the mode logic of a flight guidance system in CORE and SCR. In Proceedings of the 2"“ Workshop on Formal Methods in Software Practice (FMSP ’98), St. Petersburg, FL, March 1998. Constance Heitmeyer, James Kirby, and Bruce Labaw. Applying the SCR requirements method to a weapons control panel: An experience report. In Proceedings of the 2"" Workshop on Formal Methods in Software Practice (FMSP ’98), St. Petersburg, FL, March 1998. Anthony Torre. Project specifications for electronically controlled steering system, 1999. www. cse .msu . edu/"cse470/Public/FOO/Proj ects/steering. html. Cadence Berkeley Laboratories. Cadence SMV model checker. www-cad.eecs. berkeley.edu/"kenmcmil/smv,2000. Il Centro per la ricerca scientifica e tecnologica (ITC-irst), Carnegie Mellon University, University of Genova, and University of Trento. NuSMV: a new symbolic model checker. nusmv. irst.itc.it. Alessandro Cimatti, Edmund Clarke, Enrico Giunchiglia, Fausto Giunchiglia, Marco Pistore, Marco Roveri, Roberto Sebastiani, and Armando Tacchella. NuSMV Version 2: An OpenSource Tool for Symbolic Model Checking. In Pro- ceedings of the International Conference on Computer-Aided Verification (CAV 2002), volume 2404 of LNCS, Copenhagen, Denmark, July 2002. Springer. Sascha Konrad, Laura A. Campbell, and Betty H.C. Cheng. A pattern-based approach to providing user guidance for Specifying and analyzing properties. Technical Report MSU-CSE—O4—3, Computer Science and Engineering, Michigan State University, East Lansing, Michigan, 2004. Meyer C. Tanuan. Automated analysis of unified modeling language UML specifications. Master’s thesis, University of Waterloo, August 2001. Wuwei Shen, Kevin Compton, and James Huggins. A toolset for supporting UML model checking based on abstract state machines. In Proceedings of ASE 2001, Loews Coronado Bay, San Diego, CA, November 2001. Short paper. Lin Hsin-Hung. A research of model checking UML statechart diagrams. Mas- ter’s thesis, School of Information Science, Japan Advanced Institute of Science and Technology, Japan, August 2003. Heather J. Goldsby. Specifying compositional semantic functions for non- hierarchical languages using natural deduction systems. Master’s thesis, Michi- gan State University, East Lansing, Michigan, 2004. 323 [150] Rajeev Alur. Techniques for automatic verification of real—time systems. PhD thesis, Stanford University, 1991. [151] Ron Koymans. Specifying real-time properties with metric temporal logic. Real- [152] [153] [154] [155] [156] Time Systems, 2(4):255—299, 1990. Dragan Boénaéki and Dennis Dams. Discrete-Time Promela and Spin. Lecture Notes in Computer Science, 1486:307+, 1998. Stavros Tfipakis and Costas Courcoubetis. Extending Promela and Spin for real time. In Tools and Algorithms for Construction and Analysis of Systems, pages 329—348, 1996. Marius Bozga, Conrado Daws, Oded Maler, Alfredo Olivero, Stavros Tripakis, and Sergio Yovine. Kronos: A model-checking tool for real-time systems. In A. J. Hu and M. Y. Vardi, editors, Proceedings of the 10‘“ International Confer- ence on Computer Aided Verification, volume 1427, pages 546—550, Vancouver, Canada, 1998. Springer-Verlag. Thomas A. Henzinger, Pei-Hsin Ho, and Howard Wong-Toi. HYTECH: A model checker for hybrid systems. International Journal on Software Tools for Tech- nology Transfer, 1(1—2):110—122, 1997. Betty H.C. Cheng, Enoch Y. Wang, and Robert H. Bourdeau. A graphical environment for formally developing object-oriented software. In Proceedings of the IEEE 6‘“ International Conference on Tools with Artificial Intelligence, November 1994. 324 u[jijjjijjjjgi[]le