Domain-specific model refactoring - a case study with executable gestural interaction models

Post on 25-Dec-2014

68 views 1 download

description

In this presentation we present the challenge of providing generic support for domain-specific model refactoring. We explain the need and present a solution to this problem by means of a case study. The case study uses a domain-specific modelling language for specifying and refactoring executable models of applications that use gestural interactions (hand movements) to control virtual objects in a 3D environment.

transcript

Challenges  in  so,ware  refactoring  Tom  Mens  and  Romuald  Deshayes  

Faculty  of  Sciences,  University  of  Mons,  Belgium  

Dagstuhl  Seminar  14211  “The  Future  of  Refactoring”    19-­‐23  May  2014,  Germany  

Challenge    Domain-­‐specific  model  refactoring  

•  Context  –  Executable  so,ware  models  are  expressed  in  a  domain-­‐specific  modeling  language  

•  Goal  –  Facilitate  model  development  by  providing  model  refactoring  support  

–  Verify  behaviour  preservaPon  •  Challenge  

–  Provide  generic  support  for  domain-­‐specific  model  refactoring    

•  Case  study  –  Develop  executable  models  of  HMI  applicaPons  using  gestural  interac5on  with  virtual  3D  objects  

Case  study:  gestural  interacPon  

•  ManipulaPng  books  on  a  virtual  bookshelf  

PUT  SCREENSHOT  HERE  

Case  study:  gestural  interacPon  

•  ManipulaPng  books  on  a  virtual  bookshelf  – Executable  model  is  expressed  in  GISMO  DSML  

Case  study:  gestural  interacPon  

ShooPng  arrows  with  a  virtual  bow  

Domain-­‐specific  model  refactoring  

•  Expressed  as  graph  transformaPons  (in  AtoMPM)  •  Refactoring  examples  

1.  Add  reflexive  gesture  2.  Switch  le,  and  right  hand  gestures  

R_RightToLe,  

Domain-­‐specific  model  refactoring  Behavior  preservaPon  

•  First  approach:  using  model  tesPng  – Specify  an  input  model,  run  the  applicaPon  using  the  input  model  and  verify  if  the  expected  output  is  reached  

– Example:  if  we  run  the  following  input  model  from  acPve  state  Sheathed  we  should  reach  state  Drawn  

Domain-­‐specific  model  refactoring  Behavior  preservaPon  

•  First  approach:  using  model  tesPng  

if  we  run  the  input  model  from  state  “Sheathed”  we  should  reach  state  “Drawn”  

Domain-­‐specific  model  refactoring  Behavior  preservaPon  

•  Second  approach:  by  verifying  properPes  on  the  model  

1.  Express  a  temporal  or  structural  properPes  using  the  concrete  DSML  syntax  

2.  AutomaPcally  convert  the  property  in  an  appropriate  formalism  •  E.g.  express  temporal  properPes  as  LTL  constraints  in  the  PROMELA  verificaPon  modeling  language  

•  E.g.  express  structural  constraints  using  OCL  3.  Use  model  checkers  to  verify  preservaPon  of  properPes  

before  and  a,er  the  model  refactoring  •  E.g.  SPIN  model  checker  for  temporal  constraints  in  PROMELA  •  E.g.  OCL  model  checker  for  structural  constraints  

Domain-­‐specific  model  refactoring  Behavior  preservaPon  

•  Examples  of  temporal  proper5es  –  (Specific)  A  bow  cannot  be  bent    before  having  placed  an  arrow  on  it  

–  (Specific)  It  should  always  be  possible  to  return  to  the  “sheathed”  state  

–  (Generic)  Every  gesture  in  the  model  should  eventually  be  able  to  be  triggered  

–  (Generic)  Every  state  should  be  reachable  from  every  other  state  

Domain-­‐specific  model  refactoring  Behavior  preservaPon  

•  Examples  of  structural  proper5es    –  If  a  bow  is  in  the  bending  state,  the  number  of  available  arrows  must  be  >0    

– A  bow  cannot  be  manipulated  by  more  than  one  hand  

Domain-­‐specific  model  refactoring  Model  improvement  

•  Apply  model  refactorings  to  resolve  model  smells  – Model  smells  =  desired  properPes  that  are  not  saPsfied  by  the  model  •  E.g.  It  should  always  be  possible  to  return  to  the  Sheathed  state  •  This  property  is  not  verified  in  the  following  model  è  

Domain-­‐specific  model  refactoring  Model  improvement  

•  Apply  model  refactorings  to  resolve  model  smells  – Model  smells  =  desired  properPes  that  are  not  saPsfied  by  the  model  •  E.g.  It  should  always  be  possible  to  return  to  the  Sheathed  state  •  Adding  a  gestural  transiPon  from  Drawn  to  Sheathed  makes  the  property  verified  è  

Further  Reading  •  J.  Zhang,  Y.  Lin,  J.  Gray.  Generic  and  Domain-­‐Specific  Model  

Refactoring  Using  a  Model  TransformaPon  Engine.  In  Model-­‐Driven  So,ware  Development,  Springer  (2005)  

•  T.  Mens.  On  the  use  of  graph  transformaPons  for  model  refactoring.  GTTSE  (2006)  

•  R.Deshayes,  Ph.  Palanque,  T.  Mens.  A  generic  framework  for  executable  gestural  interacPon  models.  VL/HCC:  35-­‐38  (2013)  

•  R.  Deshayes:  A  domain-­‐specific  modeling  approach  for  gestural  interacPon.  VL/HCC:  181-­‐182  (2013)  

•  R.  Deshayes,  T.  Mens,  Ph.  Palanque.  PetriNect.  A  tool  for  executable  modeling  of  gestural  interacPon.  VL/HCC:  197-­‐198  (2013)  

•  B.  Meyers,  M.  Wimmer,  H.  Vangheluwe.  Towards  domain-­‐specific  property  languages:  The  ProMoBox  approach.  Proc.  ACM  workshop  Domain-­‐Specific  Modeling  (2013)