Transforming timing diagrams into knowledge acquisition in automated specification

Requirements engineering is an important part of developing programs. It is an essential stage of the software development process that defines what a product or system should to achieve. The UML Timing diagram and Knowledge Acquisition in Automated Specification (KAOS) model are requirements engineering techniques. KAOS is a goal-oriented requirements approach while the Timing diagram is a graphical notation used for explaining software timing requirements. KAOS uses linear temporal logic (LTL) to describe time constraints in goal and operation models. Similarly, the Timing diagram can describe some temporal operators such as X (next), U (until) and R (release) over some period of time. Thus, our aim is to use the Timing diagram to generate parts of a KAOS model. In this paper we demonstrate techniques for creating a KAOS goal model from a Timing diagram. The Timing diagram which is used in this paper is adapted from the UML 2.0 Timing diagram and includes features to support translation into KAOS. We use a case study of a Lift system as an example to explain the translation processes described here

Timing diagrams add Requirements Engineering capability to Event-B Formal Development

Event-B is a language for the formal development of reactive systems. At present the RODIN toolkit [15] for Event-B is used for modeling requirements, specifying refinements and doing verification. In order to extend graphical requirements modeling capability into the real-time domain, where timing constraints are essential, we propose a Timing diagram (TD) [13] notation for Event-B. The UML 2.0 based notation provides an intuitive graphical specification capability for timing constraints and causal dependencies between system events. A translation scheme to Event-B is proposed and presented. Support for model refinement is provided. A partial case study is used to demonstrate the translation in practice

Bringing requirements engineering to formal methods: timing diagrams for Event-B and KAOS

Event-B is a language for the formal development of reactive systems. At present the RODIN toolkit (RODIN, 2009) for Event-B is used for modelling requirements, specifying refinements and verification. In order to extend the ability to model graphically requirements for the real-time domain, where timing constraints are essential, we use Timing diagrams for Event-B, UML-B and Knowledge Acquisition in autOmated Specification (KAOS). The Timing diagrams, based on UML 2.0 Timing diagram notation (OMG, 2007), provide an intuitive graphical specification capability for timing constraints and causal dependencies between system events. Translation schemes to Event-B, UML-B and KAOS are proposed and presented.The benefit of our contribution is providing a graphical option to generate timing constraints and causal dependencies of a reactive system to Event-B, UML-B and KAOS Goals. Thus, instead of manually generating these Event-B, UML-B and KAOS Goal models in a textual form, users can use the TD as a graphical front-end, and these target models are created automatically.We compare the three applications of the Timing diagrams in terms of their contribution to formal requirements engineering. A partial case study of a Lift System is used to demonstrate the translation in practice

Enhancing B-Method by Timing Diagram

A Formal method is a requirements engineering technique used for specification, development and verification of software. B-Method is a Formal Method approach which uses set theoretic notations to specify and model systems. Event-B is adapted from the B-Method. Its events occur spontaneously rather than being invoked. Therefore, Event-B is suitable for reactive and real time systems. However, Event-B lacks remarkable features for identifying time constraints, such as Timing diagrams. Thus, the Timing diagram is introduced in this paper for enhancing the Event-B. In this paper we demonstrate techniques to create an Event-B model from the Timing diagram. We propose a pattern to transform the Timing diagram into the Event-B model. The Timing diagram which is used in the paper is adapted, from UML 2.0 Timing diagram, to have features to support translating from the Timing diagram into the Event-B model. We use a case study: a Lift Display system as an example for translating