In conclusion: We tried to bridge the existing gap by suggesting a transformation methodology and a toolset in order to verify UML models,based on sequence diagrams. We wanted to preserve the Object Oriented aspects in the target formal model. The idea is for engineers to stay in the UML domain in the verification process. We applied it to a distributed object-oriented system, and discovered a logical flaw that prevents progress of jobs. Since we're aiming for a push-button approach, the number one problem we're currently tackling is expressing properties in the UML world too. Sequence diagrams can be easily translated into these temporal logic formulas of accept or reject scenarios, given that actions in the model correspond to message exchanges in sequence diagrams, but we're evaluating to what extent SDs can express just about any requirement.
NASA Formal Methods Symposium
From UML to Process Algebraand Back:An Automated Approach to Model-CheckingSoftware Design Artifacts of Concurrent SystemsDaniela Remenska, Jeff Templon , Tim A.C. Willemse,Philip Homburg, Kees Verstoep , Adria Casajus , and Henri BalNASA Formal Methods SymposiumMay 2013
Model checking: a success story?Model CheckerSoftware/HardwareSystemNope, youregood to go!Houston, wehave a problem!Are theredeadlocks inmy system?
Are theredeadlocks inmy system?Model CheckerSoftware/HardwareSystemNope, youregood to go!Houston, wehave a problem!Model checking: a success story?
Why state-of-the-art is not yetstate-of-the-practice?● SE wants efficient push-button verification solutions● Not everything is implemented in Java / C / Matlab● Not everything is described in a domain-specific verifiable language● Need to write a funky model in process algebra?● Forget it, lets just stick to testing and static analysis.● UML is the lingua franca for describing systems● Intuitive, visual, lots of CASE tools, automated test/code generation● Not officially formalized!
The rationale: treating objects assequential processesTimeObjects (lifelines)"The general UML-to-Promela formalization approach is to mapobjects to processes in Spin (proctypes) that exchange messages...""...lines 7 and 8 specify the lifelines using process..."Executionoccurrence
Objects: sequential or concurrent?In a concurrent setting, multiple threads of a process could beinvoking methods on the same object.
The rationale: global choices- managing choices globally- dealing only with synchronouscommunication- not treating all Fragment typesWhy should object a need to knowlocal decisions of object b ?
Goal: preserve the OO view in thetarget model● An OS level process is essentially a chain ofmethod invocations on objects● Associate an mCRL2 process description witheach class method– Each mCRL2 process instance carries informationabout the class, object, and OS process instance towhich the method behavior belongs● Trivial to reverse model-checking traces back tothe UML domain
Validation● UML specification is semi-formal– Semantics deduced via partial meta-model views& natural language descriptions– No mathematically-formalized semantics– We dont have formal correctness proofs tosupport the validity of this transformation– Simulation on simple building blocks; applicationon a real case study
$ java jar UML2mCRL2 exportedModel.uml model.mcrl2 $ mcrl22lps nfbw model.mcrl2 model.lps$ lps2pbes model.lps model.pbes –formula=formula.mcf$ pbes2bool model.pbes[true* .synch_call(1,ExecutorQueues,_queues,pushTask(JobPath,taskId,false)).true*.!(synch_call(1,ExecutorQueues,_queues,popTask([JobPath])))*.synch_reply(1,ExecutorDispatcher,_eDispatch,_sendTaskToExecutor_return(OK,0))]false● Problem: state-space explosion!- 50 processes in the model- >300million states and >600GB of memory● Workaround: standard monitoring automaton running lock-step with the model, fires a deadlock action if a violation isfound
Conclusions and Future Work● Attempt to bridge the existing gap by providingtransformation methodology and toolset●Express properties in UML rather than with µ-calculus[true* .synch_call(1,ExecutorQueues,_queues,pushTask(JobPath,taskId,false)).true*.!(synch_call(1,ExecutorQueues,_queues,popTask([JobPath])))*.synch_reply(1,ExecutorDispatcher,_eDispatch,_sendTaskToExecutor_return(OK,0))]falseremember this?