The ESSENCE Language. Concepts, Examples, Insights. by Ivar Jacobson, Michael Striewe, Ashley McNeile

Transcription

1 The ESSENCE Language Concepts, Examples, Insights by Ivar Jacobson, Michael Striewe, Ashley McNeile

2 Part 1 A QUICK OVERVIEW OF ESSENCE

3 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

4 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

5 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

6 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.

7 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

8 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

9 Alphas in the SEMAT Kernel

10 AcLvity Spaces in the SEMAT Kernel

11 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

12 The concept of Sub- Alphas

13 Part 2 BUILDING A SAMPLE PRACTICE

14 SCRUM and the Kernel Alphas SEMAT Kernel The 4th Semat Workshop December 15-17, 2011 Stockholm 14

15 Step 1: IdenLfy relevant kernel Alphas Sample praclce: Scrum Scrum Requirements Work Team Software System

16 Step 2: Add a sub- alpha OpLonal step, but helpful in our example Reminder: Sub- Alphas drive their parent Alphas Sprint Drives Work

17 Step 3: Add some work prodcuts

18 Step 4: Organize aclviles Relate to aclvity spaces and define ordering

19 Part 3 ENACTMENT

20 Introducing the enactment level MOF level 2: The ESSENCE meta model Defines the Essence concept WorkProduct. WorkProduct These are pre- defined as part of the Esssence Language These are defined by the Method Engineer to describe parlcular PracLces/Methods MOF level 1: A praclce descrip;on Defines the common aoributes that every WorkProduct must have. my_workproduct Use Case NarraLve MOF level 0: Work happening on an actual project The Enactment Level These populated by PracLLoners when a project is enacted Use Case NarraLve for: Withdraw Cash

21 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

22 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

23 Finding out where you are Check Points are used to determine the current state of an Alpha at any Lme

24 GeneraLng advice what to do next 1. Where are we now? 2. Where do we want to be? 3. Which Ac5vi5es have the target state as a Comple5on Criterion? 4. How are the required Ac5vi5es performed? Architecture Selected Architecture Selected Tasks to be performed Demonstrable Demonstrable Implement Server Infrastructure Work Products to be used Usable Ready Usable Ready Demonstrate Performance Prototype Tasks to be performed Work Products to be used Operational Operational Confirm Nonfunctional Requirements Compliance Tasks to be performed Retired Retired Work Products to be used

25 Part 4 COMPOSITION

26 PracLce composilon CreaLon of big praclces out of small ones Merging of elements from different praclces =

27 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

28 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

29 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

30 Part 5 INSIGHTS FROM THE DESIGN PROCESS

31 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,

32 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

33 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

34 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 ActivitySpaceAndActivity AlphaAndWorkProduct prefer incremental layers Foundation Competency View

35 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

36 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!

37 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