Specifying embedded systems with statecharts and Z: An agenda for cyclic software components

Grieskamp, Wolfgang; Heisel, Maritta; Dörr, Heiko

doi:10.1007/bfb0053585

Cited by 23 publications

(9 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Grieskamp et al demonstrated the use of the agenda approach to support the systematic development of requirement specifications for a particular class of embedded safetycritical systems [25]. An agenda is a list of steps to be accomplished when carrying out some task in the context of software engineering.…”

Section: Related Workmentioning

confidence: 99%

On Comparing and Complementing two MBT approaches

Cristiá

Júnior

Vijaykumar

2010

2010 11th Latin American Test Workshop

View full text Add to dashboard Cite

Abstract-At INPE1 researchers and software engineers have been using Statechart-based testing for some time to test on-board satellite software. On the other hand, a group of researchers at CIFASIS 2 and Flowgate Consulting have been applying Z-based testing for unit testing. Both groups started to compare their approaches and tools a year ago. What started as a comparison to share ideas and results, is now turning into the realization that actually both techniques complement and benefit from each other, yielding a more effective and wider Model-Based Testing (MBT) approach. In this paper we present the results obtained so far in comparing and complementing these two MBT techniques.

show abstract

Section: Related Workmentioning

confidence: 99%

On Comparing and Complementing two MBT approaches

Cristiá

Júnior

Vijaykumar

2010

2010 11th Latin American Test Workshop

View full text Add to dashboard Cite

show abstract

“…Combining Statecharts and Z for the design of safety-critical control systems [75] (1996), Integrated Formal Methods [17] (1996), A combination of Object-Z and CSP [14] (1997), Specifying embedded systems with Statecharts and Z [19] (1998), An Operational Semantics for Timed RAISE, TRSL [18] (1999), Linking DC together with TRSL [30] (2000), Study of graphical and temporal specification techniques [49] (2003), Integration of Specification Techniques [48] (2003).…”

Section: Integrating Formal Techniquesmentioning

confidence: 99%

“…Many other references could be given to papers that seeks to provide answers to integration issues: [75,17,14,32,19,11,60,77]. …”

Section: Integrating Formal Techniquesmentioning

confidence: 99%

See 1 more Smart Citation

“UML–ising” Formal Techniques

Bjørner

George²,

Haxthausen

et al. 2004

Integration of Software Specification Techniques for Applications in Engineering

View full text Add to dashboard Cite

Abstract. This invited paper presents a number of correlated specifications of example railway system problems. They use a variety of partially or fully integrated formal specification. The paper thus represents a mere repository of what we consider interesting case studies.The existence of the Unified Modeling Language [10,67,36,20] has caused, for one reason or another, the research community to try formalise one or another facet of UML. In this paper we report on another way to achieve what UML attempts to achieve: Broadness of application, convenience of notation, and multiplicity of views. Whether these different UML views are unified, integrated, correlated or merely co-located is for others to dispute. We also seek to support multiple views, but are also in no doubt that there must be sound, well defined relations between such views.We thus report on ways and means of integrating formal techniques such as RAISE (RSL) [18,45,46], and TRSL with Duration Calculus [79,30]. In this way one achieves a firm foundation for combined uses of these formal development techniques, one that can be believably deployed for as wide a spectrum, or even a wider spectrum of software (and hardware) development, as, respectively than UML.1 The Problem The IssuesWhen we describe, in informal, yet reasonably precise natural (or at least domain specific professional) language the entities, the functions, the events and behaviours of an application domain, then we encounter, perhaps, little, if any problem. Our use of natural language is very flexible. Without hardly noticing it, we slip from one mode of description to another mode. (What these modes are will be apparent in the next paragraph.)When, now, on the basis of the informal narrative, we wish to formalise this description, then we might very well encounter serious problems. We refer here to the current inability of any one formal specification language to cater for all kinds of modes: Functional, imperative (ie., with states being changed by assignments to variables), logical, temporal, and concurrency modes, the latter with events and behaviours. In particular we often slip, in natural language, from describing such qualitative aspects of timing as concurrent behaviours and their synchronisation and communication, to such quantitative aspects of timing as absolute and relative time: "12:05 am" to "after 5 minutes and 30 seconds" -without hardly noticing it.

show abstract

“…The Zed notations were type checked with the ESZ type checker but the Statechart semantics were not fully formalized. In addition, we reviewed several other case studies that utilized Zed for concretely defining data while using Statecharts as a behavioral description and evaluation method [7][8][9].…”

Section: Related Workmentioning

confidence: 99%