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