The  ESSENCE  Language    

Concepts,  Examples,  Insights    

by  Ivar  Jacobson,  Michael  Striewe,  Ashley  McNeile  

A  QUICK  OVERVIEW  OF  ESSENCE  Part  1  

The  Task  at  Hand  

•  Design  a  language  …  – …  that  can  describe  prac;ces  in  SoGware  Engineering  

– …  that  is  independant  from  fads,  but  based  on  universal  knowledge  

– …  that  can  be  used  to  check  progress  and  health  of  your  project  

– …  that  is  easy  to  learn  and  use  

Based  on  two  fundamental  principles  

•  Agile  in  working  with  methods  – Keep  pracLces  lean  – AdaptaLon  of  pracLces  during  an  endeavor  

•  SeparaLon  of  Concerns  – SeparaLng  the  essenLals  from  the  specifics  – SeparaLng  abstract  concepts  from  actual  things  –  IdenLfying  e.g.  cross-­‐cuPng  pracLces  

Agile  in  Working  with  Methods  

•  Agile  means  light  and  lean  •  Design  complete  flows  as  pracLces  •  Focus  on  doing  rather  than  descripLon  

– People  are  no  robots  controlled  by  methods!  – AdaptaLon  during  usage  happens  anyway  –  thus  it  must  be  supported  

– Measure  progress  and  health  while  using  a  pracLce  

SeparaLon  of  Concerns  •  Basic  users:  A  large  user  group  whose  members  are  happy  with  the  kernel  

alphas  and  with  pracLces  but  no  formal  acLviLes.    PracLces  are  in  plain  English  with  references  to  alphas,  and  possibly  their  states.  

•  Casual  users:  Students  and  teachers  of  soGware  engineering  and  small  teams  on  short  term  projects  need  a  lightweight  kernel.  They  need  a  broad  but  not  in-­‐depth  coverage  of  kernel  &  language  (textual  and  graphical),  to  expose  and  make  them  prepared  for  higher  responsibiliLes.    

•  Advanced  users:  SoGware  pracLLoners  working  on  mid  to  large  scale  projects  need  a  rich  kernel  which  they  can  uLlize  to  reuse  /  define  their  pracLces  and  monitor  progress  and  health  of  their  work.  They  would  welcome  community  defined  alpha  extensions  and  standard  /  custom  pracLces  along  with  tools  to  manage  them.  

•  Expert  users:  The  consultants,  pracLce  experts,  method  engineers  and  tool  providers  would  like  to  have  a  robust  framework  which  they  can  extend  as  needed  for  their  clients.  

Language  Design  for  ESSENCE  

•  Syntax  – Strikingly  easy  graphical  syntax  required!  – Textual  syntax  of  minor  importance  

•  SemanLcs  – Some  staLc  semanLcs  – Dynamic  semanLcs  are  important!  

•  PragmaLcs  – Design  for  those  >99%  of  pracLLoners  who  are  no  methodologists  

The  six  core  elements  of  ESSENCE  

•  This  is  what  word  types  (nouns,  verbs,  arLcles,  …)  are  in  natural  language  (Quiz  quesLon:  How  many  word  types  do  you  know  for  the  English  language?)  

Alphas   AcLvity  Spaces   Work  Products   AcLviLes  

Kernels   PracLces  

Alphas  in  the  SEMAT  Kernel  

AcLvity  Spaces  in  the  SEMAT  Kernel  

A  closer  look  at  an  Alpha  

This  card  is  part  of  the  graphical  

syntax!  There  can  be  

cards  for  Alphas,  AcLvity  Spaces,  Work  Products,  and  AcLviLes  

The  concept  of  Sub-­‐Alphas  

BUILDING  A  SAMPLE  PRACTICE  Part  2  

SCRUM and the Kernel Alphas

The  4th  Semat  Workshop  December  15-­‐17,  2011  Stockholm   14

SEMATKernel

Step  1:  IdenLfy  relevant  kernel  Alphas  

•  Sample  pracLce:  Scrum  

Scrum Requirements

Work

Team

SoftwareSystem

Step  2:  Add  a  sub-­‐alpha  

•  OpLonal  step,  but  helpful  in  our  example  

Drives  Sprint   Work  

Reminder:  Sub-­‐Alphas  drive  their  parent  Alphas  

Step  3:  Add  some  work  prodcuts  

Step  4:  Organize  acLviLes  

•  Relate  to  acLvity  spaces  and  define  ordering  

ENACTMENT  Part  3  

Introducing  the  enactment  level  

Use  Case  NarraLve  

MOF  level  2:  The  ESSENCE  meta  model  

WorkProduct  Defines  the  

Essence  concept  “WorkProduct”.  

MOF  level  1:  A  pracLce  descrip;on   my_WorkProduct  

Defines  the  common  

aoributes  that  every  

WorkProduct  must  have.  

MOF  level  0:  Work  happening  on  an  actual  project  

Use  Case  NarraLve  for:  

“Withdraw  Cash”  

These  are  pre-­‐defined  as  part  of  the  Esssence  Language    

These  are  defined  by  the  “Method  Engineer”  to  

describe  parLcular  PracLces/Methods  

These  populated  by  PracLLoners  when  a  project  is  enacted  

The  “Enactment  Level”  

PopulaLng  the  enactment  level  (1)  

•  Level-­‐0  is  populated  “top  down”  as  a  project  enactment  progresses,  starLng  with  the  top  level  Alphas  defined  by  the  Kernel  

PopulaLng  the  enactment  level  (2)  

•  Detail  is  added  as  the  project  enactment  progresses,  primarily:  – Sub-­‐Alphas  (Team  Members,  Tasks,  Risks,  SoGware  Components,  etc.)  

– Work  Products  (Project  Plans,  Use  Case  DescripLons,  UML  Models,  Test  Plans,  Risk/Issue  Registers,  etc.)  

•  The  Sub-­‐Alphas  and  Work  Products  required  is  defined  by  the  PracLces  being  used  

Finding  out  where  you  are  

•  “Check  Points”  are  used  to  determine  the  current  state  of  an  Alpha  at  any  Lme  

GeneraLng  advice  what  to  do  next  1.  Where  are  we  now?  

Architecture Selected

Demonstrable

Usable

Operational

Retired

Ready

2. Where  do  we  want  to  be?  

Architecture Selected

Demonstrable

Usable

Operational

Retired

Ready

3. Which  Ac5vi5es  have  the  target  state  as  a  Comple5on  Criterion?  

Implement Server

Infrastructure

Confirm Non-functional

Requirements Compliance

Demonstrate Performance

Prototype

4. How  are  the  required    Ac5vi5es  performed?  

Tasks to be performed

Work Products to be used

Tasks to be performed

Work Products to be used

Tasks to be performed

Work Products to be used

COMPOSITION  Part  4  

PracLce  composiLon  

•  CreaLon  of  big  pracLces  out  of  small  ones  •  Merging  of  elements  from  different  pracLces  

=  

Using  extensions  

•  Extensions  are  a  means  of  separaLon  of  concern  

•  Everything  must  be  extendable  – Extensions  to  single  elements  – PracLce  or  Kernel  extensions  

+  More  alphas  

(some  as  Sub-­‐Alphas)  and  Alpha  AssociaLons  

=   Embedded  SoQware  

Engineering  

Organizing  large  Libraries  

•  The  “world  wide”  universal  knowledge  goes  to  a  kernel  

•  Company  wide  universal  knowledge  goes  to  a  kernel  extension  

•  Domain  specific  Work  Products,  AcLviLes,  and  PracLces  go  to  different  Libraries  

•  Project  specific  enactable  pracLce  (=  method)  is  build  on  top  of  all  of  that  

PracLcal  consideraLons  

•  ComposiLon  can  be  done  physical  via  the  cards  from  the  graphical  syntax!  – Place  a  set  of  Kernel  cards  on  the  table  – Select  some  decks  of  cards  from  the  Library  – Stack  cards  on  each  other  for  composiLon  

•  This  makes  to  process  touchable  to  pracLLoners  

INSIGHTS  FROM  THE  DESIGN  PROCESS  

Part  5  

The  process  to  define  the  language  

•  IteraLve,  agile  process  -­‐  but  within  OMG  RFP  procedure  – Kick-­‐Off  version  based  on  previous  work  –  IniLal  submission  in  February  2012  – Revised  submission  in  August  2012  – Final  submission  to  come  in  November  2012  

•  Work  in  an  internaLonal,  distributed  team  – Language  experts,  pracLLoners,  PhD  students,  …  

Working  with  the  Kernel  team  

•  Kernel  team  …  – …  worked  on  Alphas  and  AcLvity  Spaces  in  parallel  to  language  development  

– …  provided  requirements  for  the  language  – …  had  own  ideas  on  semanLcs,  but  did  not  drill  down  to  language  spec  details  

– …  was  the  first  team  to  actually  use  the  output  from  language  design  

How  to  review  an  evolving  spec  

•  ConLnuous  review  within  the  language  team:  – Proposals,  discussions,  draGs,  comments  to  the  draG,  revisions,  …  

•  Pre-­‐submission  review  by  the  kernel  team:  – Complete  draG  read  by  non-­‐language  people  

•  Submission  review  by  external  reviewers:  – Other  language  people,  tool  builders,  pracLLoners,  compeLng  OMG  submission  teams    

Packages  and  layers  

•  How  to  organize  a  language  (meta  model)?  •  Language  people  and  tool  vendors  …  

– …  love  packages  – …  are  fine  with  package  dependency  graphs  

•  Users  and  learners  …  – …  love  incremental  steps  – …  prefer  incremental  layers  

Foundation

AlphaAndWorkProduct

ActivitySpaceAndActivity Competency

View

Different  syntaxes  

•  Graphical  syntax  is  key!  – Diagrams  –  that’s  the  usual  thing  – Cards  –  that’s  new  and  touchable  (and  mixes  graphical  elements  with  textual  elements)  

•  Plain  textual  syntax  is  of  minor  importance  •  Only  language  people  want  to  see  meta  models  from  the  abstract  syntax  

Tool  support  

•  People  trust  syntax  more  if  they  see  it  in  acLon  in  a  tool  

•  Early  prototypes  of  tools  provided  in  parallel  to  language  development  – One  for  organizing  virtual  cards  – One  for  the  textual  syntax  

•  But  don’t  forget:  Physical  cards  and  a  whiteboard  are  tools,  too!  

Lessons  learned  

•  Separate  the  word  types  (=  language  elements)  from  the  words  (=  Kernel  and  PracLce  elements)  

•  Design  from  a  user’s  perspecLve  and  keep  technical  details  (=  meta  models)  under  the  hood  

•  Making  a  large  language  is  easy  –  keeping  it  small  is  the  harder  job