Next  Genera*on  Model-‐Driven  Development  for  Agile  Projects  

Objec*ves  

•  Drive  down  development  *me  and  costs  and  increase  product  quality  

•  Proac*vely  head  off  technical  debt  and  ensure  architectural  integrity  

•  Jump  start  development  projects  with  proven  conven*ons  •  AEain  solu*on  space  knowledge  con*nuity  •  Drive  down  maintenance  costs  •  Enable  plaHorm-‐level  refactoring  

Balance  Concerns  

Architectural  Integrity  

Rapid  Delivery  

Why  Model?  

•  Models  provide  a  representa*on  of  problem  and  solu*on  space  knowledge  that  is  portable  and  persistent  

•  Common  lexicon  for  communica*ng  concepts  and  building  understanding  across  all  developers  

•  Picture  is  worth  1000  words  

•  Basis  for  conversa*on  about  the  rela*onships  of  key  abstrac*ons  in  a  system  

SoRware  is  Executable  Knowledge*  

•  Books  and  similar  media  contain  sta*c  knowledge  •  SoRware  encapsulates  knowledge  about  how  to  solve  a  

problem  in  such  a  way  that  the  applica*on  of  that  knowledge  can  be  automated  

•  Model-‐driven  development  allows  us  to  use  soRware  to  automate  our  knowledge  about  how  to  implement  soRware  systems  

*  Of  Zeppelins  and  Jet  Planes;  Phil  Armour  

Model-‐Driven  Architecture  Theory  

•  A  methodology  wherein  system  func*onality  is  defined  as  a  plaHorm-‐independent  model,  using  an  appropriate  specifica*on  language  and  then  translated  to  one  or  more  plaHorm-‐specific  models  for  the  actual  implementa*on  

•  The  executable  soRware  is  an  output  of  a  system  which  takes  a  technology-‐independent  descrip*on  of  the  solu*on  as  an  input  

Not  Just  Code  Genera*on  

•  A  way  to  con*nuously  encapsulate  new  development  knowledge  in  ways  that  can  automate  development  

•  Retain  key  business  knowledge  across  heterogeneous  technologies  

•  Allow  developers  to  focus  their  crea*vity  on  parts  of  the  system  that  maEer  the  most  to  users  

•  Not  just  point-‐in-‐*me  ac*vity  

Types  of  Models  

•  PlaHorm-‐Independent  Model  (PIM)  –  Describes  the  business  concerns  of  an  applica*on  in  a  technology-‐agnos*c  

way  –  Describes  how  the  system  will  solve  the  acceptance  criteria  –  Bridges  between  problem  and  solu*on  spaces  –  Holds  true  regardless  of  what  technology  is  used  to  implement  the  system  

•  PlaHorm-‐Specific  Model  (PSM)  –  Describes  how  the  PIM  will  be  realized  using  a  specific  set  of  implementa*on  

technologies  (e.g.  Java,  .NET,  Ruby,  Objec*ve-‐C,  etc.)  

–  Describes  the  implementa*on  mechanisms  of  a  system  –  PIM  can  be  implemented  using  any  number  of  PSMs  

Keep  Models  Simple  

•  Pick  a  terse  domain-‐specific  language  for  the  PIM  •  The  more  complex  the  modeling  language  and  conven*ons,  the  less  effec*ve  it  will  be  in  communica*ng  the  essen*al  informa*on    

•  Don’t  try  to  model  everything  •  “Advances”  like  UML  2.0  actually  went  the  other  direc*on  – Made  modeling  less  accessible  –  Irony  is  the  goal  was  to  beEer  enable  MDA  

Example  DSL  For  SoRware  Systems  

•  En**es  –  Things  that  have  state  

•  Controls  –  Things  that  orchestrate  interac*on  between  en**es  to  realize  

some  func*onality  

•  Boundaries  –  Sit  between  external  actors  and  the  system  

•  Enumera*ons  –  A  fixed  list  of  values  

•  Primi*ves  –  Simple,  atomic  types  

Example  Model  

Codify  Implementa*on  PaEerns  

•  Implementa*on  paEerns  are  plaHorm-‐specific  •  Architectural  mechanisms  •  Where  do  paEerns  come  from?  

–  Previous  development  projects  –  Prototypes  –  Other  peoples’  projects  

•  Encapsulate  paEern  knowledge  into  transforma*on  templates  

•  Defines  the  development  conven*ons  

Keep  the  Transforma*on  Language  Simple  

•  Minimum  specifica*on  needed  to  access  model  elements  

•  Minimum  u*li*es  needed  to  handle  string  func*ons  like  capitaliza*on  

•  Simple  decision  structures  

Example  Transforma*on  Template  

PIM  +  Transforma*ons  =  Source  Code  

Benefits  of  MDD  

•  Improve  developer  produc*vity  –  Automate  development  of  “plumbing”  code  

•  Increase  the  value  of  each  manually  developed  line  of  code  

•  Improve  code  quality  and  maintainability  –  Conven*on-‐based  approach  limits  entry  points  for  manual  development  

–  Code  genera*on  drives  up  code  consistency  

Benefits  of  MDD  

•  Spend  more  *me  understanding  user  needs!  •  Rapidly  adapt  to  changing  needs  

–  Refactor  the  templates  to  use  new  conven*ons  or  even  new  programming  languages  

–  Preserve  plaHorm-‐independent  aspects  of  design  •  Build  systems  that  are  self-‐documen*ng  •  Spend  less  *me  star*ng  new  projects  •  Decrease  *me  to  onboard  new  developers  

Blending  MDD  and  Agile  

•  Treat  models  as  development  ar*facts  not  documenta*on  ar*facts  

•  Keep  it  simple  •  Model  and  generate  code  con*nuously  •  Make  implementa*on  knowledge  executable  to  con*nually  increase  velocity  

Minimize  Waste  &  Keep  it  Simple  

•  Only  model  parts  of  system  needed  to  implement  current  itera*on’s  stories  

•  Don’t  try  to  model  everything  –  Focus  on  key  abstrac*ons  –  Too  much  detail  leads  to  models  that  are  overly  complex  and  

difficult  to  maintain  •  Don’t  try  to  generate  all  the  code  

–  Doing  so  can  lead  to  technical  debt  in  the  transforma*on  templates  

–  Only  generate  code  for  architectural  mechanisms  you  actually  need    

–  If  figuring  out  how  to  generate  something  seems  tortured  maybe  it  shouldn’t  be  generated!  

Con*nuous  Model  Transforma*on  

•  Integrate  model  transforma*on  into  every  build  

•  Ensures  code  and  model  are  always  in  sync  

•  One-‐*me  or  infrequent  model  transforma*ons  –  Same  nega*ve  effects  as  not  doing  CI  with  source  code  –  Undermines  value  proposi*on  of  MDD  altogether  

CMT  Implementa*on  Strategy  

•  Put  boilerplate  code  in  immutable  base  classes  –  Re-‐generate  immutable  code  every  build  

•  Put  hooks  for  manual  development  in  leaf  nodes  –  One-‐*me  genera*on  of  modifiable  code,  don’t  re-‐generate  

Balance  Rigidity  Against  Flexibility  

Rigidity   Flexibility  

Puing  It  Together  

T  T  T  

Structural  key  abstrac*on  changes  

Architecturally  significant  changes  Value  added  behavioral  and    user  experience  changes  

PIM  

Transforma*ons  

Non-‐Modifiable  Code  

Modifiable  Code  

MDD  +  Tes*ng  

•  Enable  test  developers  to  focus  on  test  logic  development  

•  Use  MDD  to  generate  test  helper  components  –  User  interface  element  finders  –  Access  server  components  

•  Do  not  generate  verifica*on  logic  

Atlas  MDD  Toolkit  

•  Open  source  (hEp://atlas-‐mda.org)  •  Specifies  a  very  simple  DSL  for  describing  systems  •  Supports  any  modeling  tool  whose  model  representa*on  

can  be  adapted  to  the  Atlas  DSL  •  Model  transforma*ons  developed  using  Velocity  open  

source  template  language  •  Simple  configura*on  of  transforma*on  target  aEributes  

–  E.g.  output  path,  overwrite,  etc  •  Easily  pluggable  into  common  build  environments  

–  Maven,  Visual  Studio,  command  line,  etc  

Support  for  PSM  Guidance  

•  PlaHorm-‐specific  guidance  when  all  the  informa*on  needed  to  generate  code  doesn’t  exist  in  the  PIM  

Simple  Configura*on  

Atlas  Maven  Configura*on  

•  Plugs  into  the  generate  sources  target  

Case  Study  1  –  Failed  Project  Rescue  

•  Previous  vendor:  –  Took  3  years  to  deliver  base  func*onality  with  unsustainable  

technical  debt  –  Cost  tens  of  millions  of  dollars  

•  Using  MDD,  our  team:  –  Re-‐implemented  base  func*onality  and  established  new  

conven*ons  and  templates  in  4  months  –  Added  several  new  high-‐value  features  –  AEained  a  70/30  generated/hand-‐coded  ra*o  –  Cost  less  than  one  million  dollars  –  LeR  the  client  with  a  model  that  described  the  system  and  a  

development  plaHorm  to  add  new  features  

Case  Study  2  –  Bootstrap  Development  Team  

•  Ini*al  agile  seed  team  formulated  conven*ons  and  architectural  mechanisms  during  development  of  ini*al  stories  –  Majority  of  technical  complexity  driven  out  

•  Less  experienced  developers  added  to  mul*ply  development  throughput  –  Conven*ons  and  plumbing  already  established  –  Most  development  was  “between  the  braces”  –  New  developers  immediately  produc*ve  

•  Seed  team  detached  and  leR  less  expensive,  self-‐sufficient  team  in  place  

•  Led  to  mul*-‐million  dollar  follow-‐on  award  to  add  incremental  func*onality  on  product  base