Fully Automated Translation of BoxTalk to Promela
| dc.comment.hidden | Hello, Some of the figures in Chapter 5 (for example fig. 5.9, 5.15, etc.) are quite large. But we cannot split them, as splitting them makes it difficult to follow (We have split one figure, 5.13 though). Some algorithms in Chapter 3 (Algorithm 3.1, 3.7, 3.8 also contain lot of information and are very large which cannot be split either. | en |
| dc.contributor.author | Kajarekar, Tejas | |
| dc.date.accessioned | 2011-08-26T14:11:46Z | |
| dc.date.available | 2011-08-26T14:11:46Z | |
| dc.date.issued | 2011-08-26T14:11:46Z | |
| dc.date.submitted | 2011 | |
| dc.description.abstract | Telecommunication systems are structured to enable incremental growth, so that new telecommunication features can be added to the set of existing features. With the addition of more features, certain existing features may exhibit unpredictable behaviour. This is known as the feature interaction problem, and it is very old problem in telecommunication systems. Jackson and Zave have proposed a technology, Distributed Feature Composition (DFC) to manage the feature interaction problem. DFC is a pipe-and-filter-like architecture where features are "filters" and communication channels connecting features are "pipes". DFC does not prescribe how features are specified or programmed. Instead, Zave and Jackson have developed BoxTalk, a call-abstraction, domain-specific, high-level programming language for programming features. BoxTalk is based on the DFC protocol and it uses macros to combine common sequences of read and write actions, thus simplifying the details of the DFC protocol in feature models. BoxTalk features must adhere to the DFC protocol in order to be plugged into a DFC architecture (i.e., features must be "DFC compliant"). We want to use model checking to check whether a feature is DFC compliant. We express DFC compliance using a set of properties expressed as linear temporal logic formulas. To use the model checker SPIN, BoxTalk features must be translated into Promela. Our automatic verification process comprises three steps: 1. Explicate BoxTalk features by expanding macros and introducing implicit details. 2. Mechanically translate explicated BoxTalk features into Promela models. 3. Verify the Promela models of features using the SPIN model checker. We present a case study of BoxTalk features, describing the original features and how they are explicated and translated into Promela by our software, and how they are proven to be DFC compliant. | en |
| dc.identifier.uri | http://hdl.handle.net/10012/6135 | |
| dc.language.iso | en | en |
| dc.pending | false | en |
| dc.publisher | University of Waterloo | en |
| dc.subject | Model checking | en |
| dc.subject | Automated translation | en |
| dc.subject | SPIN | en |
| dc.subject | BoxTalk | en |
| dc.subject.program | Computer Science (Software Engineering) | en |
| dc.title | Fully Automated Translation of BoxTalk to Promela | en |
| dc.type | Master Thesis | en |
| uws-etd.degree | Master of Mathematics | en |
| uws-etd.degree.department | School of Computer Science | en |
| uws.peerReviewStatus | Unreviewed | en |
| uws.scholarLevel | Graduate | en |
| uws.typeOfResource | Text | en |