Integration of Formal Datatypes within State Diagrams

Abstract

Abstract. In this paper, we present a generic approach to integrate datatypes expressed using formal specification languages within state diagrams. Our main motivations are (i) to be able to model dynamic aspects of complex systems with graphical user-friendly languages, and (ii) to be able to specify in a formal way and at a high abstraction level the datatypes pertaining to the static aspects of such systems. The dynamic aspects may be expressed using state diagrams (such as UML or SDL ones) and the static aspects may be expressed using either algebraic specifications or state oriented specifications (such as Z or B). Our approach introduces a flexible use of datatypes. It also may take into account different semantics for the state diagrams.

Consistency in UML and B Multi-view Specifications

“…More generally, the transformation approach makes impossible opportunistic strategies where the specifier chooses at some time to focus his work on structural design with UML and at some other time to define formal properties with B, without any predefined order. Another approach consists in integrating formal definitions like data-types in UML state diagrams [2]. In our model, a specification is defined as a couple SpecUML, SpecB where SpecUML is a set of UML diagrams and SpecB a set of B machines.…”

Specification of a gas station using a formalism integrating formal datatypes within state diagrams

“…This joint use, in a formal and integrated framework, of a semi-formal notation for dynamic aspects with formal languages for static aspects enables one to take advantage of both approaches: specifier-friendliness and readability from semi-formal approaches, high abstraction level, expressiveness, consistency and verification means from formal approaches. For a comprehensive comparison with related works, the reader may refer to [6].…”

“…We first present the syntactic extensions for this integration, and then give insights into its semantics. The reader can refer to [7] for a comprehensive presentation.…”

“…Then, we have to instantiate the generic communication mechanisms and communication constraints of our approach. For short we use an asynchronous communication with event/message collections associated to the components using queues, see [6] for more detail we cannot give here by lack of place.…”

“…The pumps manager engages the /CardManagerˆupdScreen(servedqtty, amount) event and the other does the updScreen(...) event. Such an extended UML state diagrams interaction meets our general communication mechanism [6], hence it is completely formalized. These interactions with the user are continued until the end of the distribution (endDistribution) and the pump engagement (engage).…”