Model drivendeveloping

and Model based checking:

applying together

Sergey M. Staroletov

assistant professor

Altai State Technical University

Barnaul, Russia

Tools, methods and program analysis conference (TMPA-2014), Kostroma

MDD and MBTModel based developing(MDD) – is amodern technology to develop softwarefirstly focuses on the model developing, not on algorithmic and computation concepts

Achievements: UML, classes, patterns, CASE-tools

Model based testing(MBT) – technology of software testing based on comparation the model and systemunder test during the work, generationtest cases by the model, and reflectionthe system to the model for studying itsproperties.

Achievements: no such known inthe software engineering area

Problems

● Programs are going to be hard to explain and test

● Concurrent and distributive programs: no shared state, no checking the whole system logic

● No one community chosen methodology in testing based on model creation

● Good progress in verification (MBC) area● Needs to bridge together program

modeling, testing and verification

Our tasks

● Create model to describe a modern logic of interoperable multi-component concurrent program

● Create methods of how user can make the model when he has some system or how to create the system if user has the model

● Create methods how to dynamically and statically test the system with using the model

● Create demo software

Development process

User

Code

Model

Create model by the code

Create code by the model

Code+model

Dynamic testing Static analysis

Bugs

Model correction

Code fixing

How to describe the model

Has code been already

written to the timeof model creation?

Inject a model description intothe code by hand or with using

IDE addition

Implement state-based systemwith logic on the basis of our extended finite automaton

Yes No

Code creation

Model injection

Better to refactor that to

the second case

Model editing

System skeleton classes

generation

Write actual system code in the states

Three-tier model● Third tier: complex automaton, models

high lever of the interoperation

● Second tier: extended finite automaton

● First tier – state as a sequence of code lines

The model

* Graph Theory Techniques in Model-Based Testing. Harry Robinson

● We can start as a finite automaton

● Then add things we are going to model and test

● Automaton can model each component of the complex system (no global state)

Tier 2 model migration● Needs to do automaton ↔ object oriented

relation● We used to create extended automaton

description as a theoretic-set description with complex transition functions

● Then we moved to automaton descriptions as states, transitions and operations

● This model easily refers into object-oriented classes

Modeling basisWe are staying in a state. We can

Make transition to another state

Or apply a operation

Create a threadWait a thread

(with some probability)

Send a messageWait for a message

Block a common resource

Unblock a common resource

Model migration and descriprion

Model based developing

● “Switch technology”● User uses our provided classes to make

inter-operational part of the system and to describe the model

● And writes the code for states which does actual system behavior

● Approach like the same is used now in Microsoft Workflow Foundation

Dynamic testing

● How to test dynamic system by hand?

● “Printf injection” paradigm

A(); ↔ A(); printf(“\n A() done”);

B(); ↔ B(); printf(“\n B() done”);

C(); ↔ C(); printf(“\n C() done”);● Then collect state trace in one place and

check it

Dynamic testing

● Our approach is to use global server ● Which collects data from all components● Data about all model events is sent by the

code

- that preprocessor inserts to a code in the places of model description

- in our classes which user used by the model skeleton

● Server collects the global state and checks model violations

Dynamic testing● We can check:

- state visiting, transitions, events by the model

- message sending and receiving

- thread creation and joining

- resource handling● Server produces:

- state trace

- message chart diagram

- dynamic model probabilities calculation

Static verification

● In the start of research we used to apply some algorithms (graphs theory, NY street sweeper, resource waiting graphs, etc)

Than it was abandoned as:

● Now we do all the checking by using Spin verifier integrated into our system

● The goal is to map our model to Promela code and create LTL predicates

Static verification

● Problem: programmers/testers do not like to use such tools as Spin

● Our approach is to hide Promela/Spin interface and use it as a backend

● Potentially we can use other verificators and/or methods

● Model transformation is done for most common checkings that satisfy our tasks

Static verification

Statemachine, probabilities, threading, messaging are done as Promelalanguage code snippets that is being generated from our model.

Our software

Our software

● Works as an IDE extension (VS, Eclipse)● Ability to create and check model

description for the system● Set of classes that can be used as a

skeleton for interoperable state based system

● Dynamic and static checking use methods we described in this work integrated into an IDE.

Using in the education process

● Problem:

teach student not to write code first but model first

● Students thinks about some interoperation system in a real world and try to model it (systems like fast-food cafe, wedding, paying for the flat, buying the gadgets, the field of dreams TV show,...)

● Then implement it as IPC based app and network app and check the correctness

Model drivendeveloping

and Model based checking:

applying together

Q/A session

Tools, methods and program analysis conference (TMPA-2014), Kostroma