Main Page

Welcome to the IVOIRE homepage. Here we keep information about the project, the current status, our publications and the people behind the project.

The IVOIRE Idea

The IVOIRE project aims to introduce so-called Validation Obligations (VOs) into formal methods. With these VOs it then shall be possible to show whether a certain behavior is present in a formal model. By showing if a property is present, one can reason about the model and explain the features to its stakeholders. VOs will enrich the modeling process in formal methods, as shown in the picture above. While the normal refinement chain M0-M2 is already present, we plan to introduce VOs (green boxes) and various views for the model (blue boxes). The progress can be followed in detail on the Ivoire:About page. For a first deep dive into the VO semantic, see the paper that introduces IVOIRE.

Validation Obligations

Within the context of software engineering, it is vital to check whether a model meets its specification (verification) and requirements (validation). Various formal techniques exist to verify a requirements model, such as theorem proving or model checking. However, only a few formal techniques are at our disposal to validate a requirements model. In this report, we introduce a new technique with validation obligations (VOs) alongside existing proof obligations (POs) to check the compliance of a model with its requirements. A VO is composed of (multiple) validation tasks (VT) associated with a model to check its compliance with a particular requirement (formalized as VO_{id} : VO_{predicate}). The validation predicate applies the validation function on the VTs the corresponding VO is composed of. A validation task (VT) is identified with an identifier, and consists of a validation technique that is applied with the given validation parameters to the corresponding context (formalized as <math>VT_{id}/VT_{context}/VT_{technique}: VT_{parameters})</math>. Finally, this report demonstrates the usability of the VO approach on a simple Traffic Light example. Another important aspect is the traceability of VOs to their VTs and requirements. As shown in the Figure above, one can, e.g., see that VO18 could be traced to OCT1, TR1, TR2, and COV1, SCENARIO1, and SCENARIO2, and thus also VO12 and VO13 if it fails.

<math>a</math> <math>VT_{id}/VT_{context}/VT_{technique}: VT_{parameters})</math>