Model Driven Developing & Model Based Checking: Applying Together

Sergey M. Staroletov, assistant professor, Altai State Technical University, Barnaul, Russia

Transcript

1. Model driven developing 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
2. MDD and MBT Model based developing(MDD) – is a modern technology to develop software firstly 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 system under test during the work, generation test cases by the model, and reflection the system to the model for studying its properties. Achievements: no such known in the software engineering area
3. 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
4. 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
5. 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
6. How to describe the model Has code been already written to the time of model creation? Inject a model description into the code by hand or with using IDE addition Implement state-based system with 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
7. 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
8. 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)
9. 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
10. Modeling basis We are staying in a state. We can Make transition to another state Or apply a operation Create a thread Wait a thread (with some probability) Send a message Wait for a message Block a common resource Unblock a common resource
11. Model migration and descriprion
12. 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
13. 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
14. 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
15. 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
16. 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
17. 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
18. Static verification Statemachine, probabilities, threading, messaging are done as Promela language code snippets that is being generated from our model.
19. Our software
20. 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.
21. 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
22. Model driven developing and Model based checking: applying together Q/A session Tools, methods and program analysis conference (TMPA-2014), Kostroma