CETIC

20. The Requirements Animator

Christophe PONSARD — 2009-03-12T09:21:00Z

This article shows the goal-oriented requirements animator in action through some movies and snapshots. A demo version of the animator itself will be downloadable soon.

View the animator in action

The following videos require macromedia flash player. They were captured in 1024x768 and are best viewed in full screen or in a larger resolution.

Presentation of the train system [1'17] : this video explains the KAOS model of the railway system which will be animated. It is shown in the Objectiver requirements engineering tool in which the animator is integrated.

Starting the animator server [0'14] : this very short video show how to start an animator server and the P-FSM compilation step.

Playing a scenario with two trains [3'12] : this video truly shows the animator in action. An animator actor is started and connected to the animator server. Then a pre-recorded scenario is loaded and executed step-by-step. Various operations application are shown in parallel on multiple train/car instances: train progress, train stop at a station, door opening/closing, train/car crossing a gate, etc.

Monitoring a goal violation [2'28] : this last video shows the animator watchdog in action for monitoring a simple safety property Maintain[DoorClosedWhileMoving]. In the illustrated scenario, a model error allows a train to be started with its doors opened. Relevant events are logged and the goal violation detected. The origin of the error is then traced.

Some Animator Snapshots


Animation of the train system

10. The Refinement Checker

Christophe PONSARD — 2009-03-12T09:20:48Z

This article shows some screenshots and video of the early V&V tool in action.

What is the early formal V&V tool about ?

The purpose of this tool is to verify the correctness of KAOS constructs such as refinements and operationalisations. Those checks are local in nature and rely on the use of model-checking technology. By the production of related examples or counter-examples, this also allows the analyst to validate his work, especially when used together with the Requirements Animator.

View the tool in action

The following videos require macromedia flash player. They were captured in 1024x768 and are best viewed in full screen or in a larger resolution.

Presentation of the model of the train system [0'59] : this video explains the KAOS model of the railway system which will be animated. It is shown in the Objectiver requirements engineering tool in which the animator is integrated.

An Incorrect Goal Refinement [0'46] : in the inital model, the goal Achieve[TrainProgress] is refined into Achieve[SignalSetToGo] and Achieve[ProgressWhenSignalSetToGo]. Running the tool reveals a counter-example indicating the refinement is incomplete.

Correcting the Refinement [0'52] : the problem is fixed by requiring that a train should keep waiting by adding the goal Maintain[TrainWaiting]. The new check shows no more counter-example (on the searched domain).

Checking Operationalisations [2'52] : the verification of the equivalence between operations and the operationalized goal is illustrated on the operation MoeTrainToNextBlock and the goal Achieve[ProgressWhenGoSignal]

A Form-based Interface [2'32] : besides the textual interface, a form-based interface is also available. Through it, the analyst can easily configure the required parameters by simple drag'n drop of goals, instances, domain properties, etc.

Generating Check Reports [5'44] : this video shows how it is easy to generate both HTML and RTF documentation of the performed checks. It heavily relies on the Objectiver infrastructure for this.

[More advanced] Checking Conflicts and Obstructions [7'24] : other KAOS constructs can also be formally verified such as obstructions and conflicts. This video shows some related checks.

Some snapshots

30. The Acceptance Tests Generator

Christophe PONSARD — 2009-03-12T09:20:34Z

Acceptance tests are crucial, for example for getting the assurance that a subcontracted development meets its requirements. The FAUST generator enables the analyst to define high quality acceptance tests from requirements documents.

Acceptance Tests

The purpose of testing is to provide a reasonable assurance of the correction of the developed code. This also means that tests are not about proving the code is correct: all behavior cannot be inspected. The assurance is provided by a coverage criterion.

Several kind of tests can be distinguished because correction can be expressed in relation with different kinds of documents expressing the system behavior at different levels : from the component level (unit tests), design level (integration tests), up to the software reception by the customer (acceptance tests). Those levels are best illustrated by the "V-model" in the following figure.


The V-Model.

The purpose of the FAUST toolbox is to help achieving high assurance in the Requirements Engineering (RE) process. With respect to testing its area is acceptance testing. The approach is goal-oriented and the acceptance tests cases are thus generated from a goal-model. It has a number of interesting properties:
test generation does not require an operational model: a prescriptive model is enough (ie. a model stating the required properties but now how to achieve them). This allows one to genere high level tests without imposing specific design choices.
the coverage criterion is goal-based: the potential system behaviors stated in the goals have to be covered.
besides the goals, others concepts are also taken into accounts such as the possible refinement pattern (such as case/milestone) and obstacles/conflicts (ie impedimenting the goal realisation and thus revealing limit conditions)

In this introductory article we will just highlight how the test generator works without entering into implementation details which rely on constraint programming. For more information the interested reader is directed to the article "Deriving Acceptance Tests from Goal Requirements".

A Simple Example

As simple example, let's consider an elementary train boarding system depicted hereafter. The system is composed of a boarding block with a direct access to it and a waiting block in case a train is already on the boarding block.


Train Example: Domain.

Among the goals, one can distinguish:
progress goals, stating that every incoming train will eventually leave the system unloaded.
safety goals: train crash have to be avoided. In our system we will explicitely choose a block system design with at most one train per block.

In this example, acceptance tests generation is essentially derived from the progress goals so we will only refine them in the following figure:


Train Example: Goal Model

In the process of the elaboration of that goal model, the following object model stating the vocabulary used in the temporal logic assertion is also produced.


Train Example: Object Model.

Acceptance Tests Generation

The acceptance tests generation process is composed of two major steps:
acceptance tests classes are elaborated, for now mainly based on the information in the goal refinements. In the above example composed of one "case" refinement and two "milestone" refinement: the case refinement will give rise to two classes of step-by-step temporal behaviors.
best representatives are chosen in those tests classes based on a number of heuristics such as minimal length traces (maximal progress), reaching limit conditions (temporal constraints, untils...). Moreover some well chosen contextual information is also required such as initial/final states, and the number of instances being considered.

Acceptances tests are generated by unfolding temporal formulas which can be translated into a constraint problem for exploring all possible behaviors. Additional constraints are then added for specifying tests classes and the representative selection criterion. The resulting set of constraints is fed into a constraint solver that yields a concrete test trace.

The resulting trace can be depicted as a scenario between the system under test and its operational environment. As exemple the following figure shows an interesting limit test where two trains are introduced into the system: the first heading directly to the unload block and the second going through the waiting block until the unload block becomes free.


Train Example: Generated Test.

CRAQ155 - Certification of Software Products

Christophe PONSARD, Fabian Steels, Sebastien Dawans — 2009-03-06T16:02:56Z

The importance of certification and labeling is crucial for the regional market which is characterized by a large number of SMEs often in an improvement phase and, therefore, seeking recognition and solid partnerships in a market still wider. The mission of this project was to become a regional reference point for the software certification in a broad sense, ie to provide objective evaluation criteria, stable and consistent, which facilitate the exchange of products and services in ICT domain.

Objectives of the project

The issue of certification and / or labeling can take various forms depending on the aspect that should be certified :

The evaluation of some aspects is already governed by a standard certification following models that are standards of fact or law. For example, the models defining the level of maturity of software processes of an enterprise (the CMM which is a de facto standard in the U.S. and the Spice model becoming an ISO standard), standards defining software security levels (the Orange Book U.S., the European ITSEC and their more recent development: the common criteria). For these aspects, the objective of the centre was to become the regional point of reference with accredited assessors and, where appropriate, the necessary adaptation of these models to the regional reality.
Evaluation of other aspects such as compliance with specifications or compliance with the ergonomics is based on various criteria and pointy that are not necessarily covered by a standard. For these aspects, it is desirable to have specific and public criteria for evaluating and that they are applied in a uniform manner. In this case, the centre had to be such a reference, which has a high level of technical expertise and a total independence from the market players. It provides the necessary assessments and shall publish its criteria for giving out the status label and the necessary recognition. A suitable tool is also necessary to conduct these evaluations in an objective manner.

Through the production and dissemination of these criteria, CETIC also plays an advocacy role in the ICT market in general. This sensitization is an integral part of its missions.

Results of the project

To support the objective assessments underlying the certification process CETIC developed “D-Side Dashboard, a decision aid tool” to support project managers, quality engineers and software developers. This tool allows identifying weaknesses of the source code. For each profile, a dashboard is created specifically to improve their decision-making in the early stages of development.

Since then, several companies have asked the CETIC an opinion regarding the use and quality of third party software. The arguments, analysis and methods adopted by CETIC have always been a success.

About its position as a reference center for certification, CETIC has become a widely involved actor in various regional and federal groups, such that the label eTIC, the working group on the electronic identity card and the working group on the establishment of an evaluation using the common criteria in Belgium.

Appreciation of the project for the companies

Project 155 developed D-Side Dashboard, a tool for analysis of code. The results given by this tool are presented as a dashboard composed of graphics. Each graphic answers a question about the quality of an application. This software was used within many societies. Generally, these missions consist of the drafting of reports of static analysis of code. The companies which benefited of this expertise are, for the majority, active in the design of software for which quality is a vital criterion. D-SideDashboard was even implemented at a partner.

Partners

CRAQ153 - CEDIE

2009-03-06T12:34:03Z

Requirements engineering is a key step in the development of a computer-based system. The success of this step is crucial. However the state of practice reveals many weaknesses both in small and big companies. The CEDIE cell contributes to the improvement of the requirements engineering practices through a number of instruments such as templates, advices, training, review or coaching in requirements writing.

Objectives of the project

Requirements engineering is the initial step of every software development. It relies on a number of techniques allowing the stakeholders to express their needs and to understand the development organisation. The aim of requirements engineering is to precisely describe what is required by a software system.

This first step is also the most important one, because the work of subsequent steps will depend on it. Hence, all problems undetected at this level will inevitably reappear later but with consequences and costs far more important. The success of this step and the quality of the produced documents are thus critical. Unfortunately, large surveys have shown that more thant 2/3 of the software projects fails or run over time/budget because of problems at the requirements level.

This is even more critical when the development is externalized and thus important to spend time on the elaboration of this phase to avoid problems such as non-conformance w.r.t. user needs, inadequacy with the environment in which it should operate, etc. The contractual aspect further stresses that importance. It is thus necessary to ensure the quality of the requirements document based on a number of adequate techniques.

The objective of the Cedie is to make such techniques easily accessible to the enterprises of the region and in adequacy with their needs. This help is concrete and active, often taking the form of an implication of the requirements engineering phase of the related project. By this, the approach is integrated in a larger approach to improve quality. It will also give easier access to quality certification and improve the efficiency in the management of sub-contracting. In the end, it will boost the competitiveness of the IT enterprises.

Results of the project

,Guides, templates and trainings (use cases, UML, goal-oriented methodologies) available to the enterprises.
Organisation of information and training events (CETIC and Infopole workshops)
Advices given to a number of enterprises of the Walloon Region having contributed to the improvement of their practices in concrete cases.

Appreciation of the project for the companies

The CEDIE has delivered guides and templates enabling the improvement of a number of documents related to requirements engineering: requirements documents, tests plans, model types, etc). Those ensure a certified quality enhancing the corporate image of the IT products and enterprises of the Region.

A number of enterprises have benefited of the direct expertise of the Cedie. The majority of those are actives in the design of software requiring high quality, for example in the transport and telecom sectors.

Partners of the project

FUNDP (http://www.fundp.ac.be/)

Type of project

Walloon Region, FEDER, Phasing Out de l'Objectif 1

RETICOM (REal TIme COmmunications)

Damien HUBAUX, Sébastien Rousseaux — 2007-06-01T07:59:35Z

The objective of the RETICOM project (REal TIme COMmunications) is to study and develop a set of tools to ease the implementation of flexible and powerful communicating embedded systems.

Research Team

The RETICOM project is carried out by CETIC Embedded System team. The research is performed in collaboration with the Microelectronics Laboratory of the Université Catholique de Louvain.

Objectives

The RETICOM project started in 2001. Its objectives are to:
Study and develop signal processing algorithms for DSP and more in particular for parallel architectures.
Master development tools for this sort of architecture.
Develop libraries of functionalities for signal processing and particularly in the field of communication.
Develop a programmable platform to process in real time signals coming from a sensor network.

Application

Systems and algorithms developed within the RETICOM project enable companies and SMEs more in particular, to quickly produce flexible, programmable and efficient prototypes at low cost, corresponding to their specific needs. They also enable research teams to implement and to evaluate algorithms and hardware components developed in their laboratory.

A Methodology of Conception Based on High Level SystemC Models

RETICOM project includes a workpackage on methodology of conception-based on high level SystemC models (programming language based on a C++ modelling library and a simulation kernel). Thanks to the power and the flexibility of C++, it is possible to produce a model which can be implemented seamlessly in the design flow. The introduction of software concepts and techniques (UML specification, design patterns) can really add value to the development of electronic systems.

Communicant, Flexible and Smart Systems

The signal processing systems built in this project are based on programmable logic devices (FPGA). A study of processors implemented in programmable logic has lead to the development of a “powerful” framework named SAND. This framework is composed of an embedded system based on a FPGA containing a “soft processor”. This architecture provides a high level of hardware and software flexibility. The SAND provides several wired and wireless communication interfaces. At software level, an embedded Linux has been adapted to run on the platform and provides stability, flexibility, efficiency to the system, allowing standardised access to its peripherals.

The SAND platform, currently in advanced prototyping phase, is used as a base to develop the libraries of functionalities. Among these are:
Processing functions for automotive data analysis. The SAND provides built-in CAN (FMS) / OBD2 communication interfaces to acquire vehicle data (speed, rpm, fuel consumption, throttle, etc). Thanks to its processing power, it is able to process data on-the-fly and store the results in non volatile memory.
Data acquisition and processing functions for data coming from sensors: temperature, position (GPS),...
The use of programmable logic devices eases the implementation of controllers for communication protocols.

Given its flexibility, its power and its numerous communication interfaces, the SAND turns out to be an appropriate tool for future researches on study and development of wireless heterogeneous communication systems (supporting several interfaces).

In order to extend its panel of application, the RETICOM project also leads to the development of a lightweight framework, called WAND. Based on Bluetooth communication technology this device is programmable and low power. Its main goal is to acquire data from various sources and to send these data intelligently using an opportunistic routing methodology through several possible ways (GSM, PDA, Computer). The e-heatlh applications are a typical use of the WAND.

Scientific Advisors

Promoters of RETICOM project are three professors of the Université Catholique de Louvain : Jean-Didier Legat (DICE), Luc Vandendorpe (TELE) et Michel Verleysen (DICE).

Method

Fabrice ESTIEVENART — 2003-09-30T09:50:34Z

Our web sites reverse engineering method is composed of five processes :

Web pages classification

Web pages within a site can be gathered into semantic groups according to their informational content. A page type is a set of pages relative to a same concept. For example, all pages describing the departments of a company belong to the page type "Department".

HTML cleaning

All HTML pages that should be analysed are transformed into well-formed XML documents in order to allow easy parsing and extraction.

Semantic enrichment

Before data and schema extraction, we need to know, for each page type, what are the concepts displayed and where they are located in the HTML tree. For example, a page type "Department" will be composed of the concepts "Name", "Address" and "Activities". All semantic information provided by the user during that step will be stored into an XML document called the META file.

Data and schema extraction

When the META file have been completed (i.e. it contains sufficient information to describe all the pages of the same type), it can be used to extract data from HTML pages and to store them in an XML document. This data-oriented document has to comply with an XML Schema that is also automatically extracted from the META file.

Schemas integration and conceptualisation

If a site comprises several page types, their XML Schemas must be integrated into a integrated logical schema that can then be conceptualized to represent the application domain covered of the whole web site.


The web site reverse engineering method

see the paper we submitted for WSE 2003

Tools

Fabrice ESTIEVENART — 2003-09-30T08:03:53Z

- Web site reverse engineering

The web sites reverse engineering tools

Fabrice ESTIEVENART — 2003-09-29T12:52:41Z

Our web sites reverse engineering method allows to extract from a web site the data and their schemas. It is supported by multiple tools.

The semantic browser

That plug-in for the Mozilla web browser allows a user to select and give a name to some parts of an HTML document. Using these semantic information, a META file can be automatically generated.

The data extractor

On the basis of the information provided by a META file, that Java tool parses web pages in order to extract data and store them in an XML document.

The schema extrator

That Java parser extracts from a META file the XML Schema document that validates the previously extracted data.

DB-Main

The CASE tool DB-Main is used to integrate the extracted XML Schemas and conceptualise that logical structure. The resulting conceptual schema is an abstract representation of the data of the whole web site.

see the paper we submitted for WSE 2003

The XML code generator

Fabrice ESTIEVENART — 2003-09-29T11:41:35Z

The XML code generator is integrated in the DB-Main CASE tool.

From a schema conform to the XML model (DTD or XML Schema), it automatically generates the corresponding data definition code.


XML code generation in DB-Main