A template-based analysis of the GRL EMMSAD 2005, june 13-14, Porto

1. A template-based analysis of the GRLEMMSAD 2005, june 13-14, Porto Gautier Dallons, Patrick Heymans, Isabelle Pollet University of Namur (Belgium) PRECISE research lab www.info.fundp.ac.be/PRECISE We thank Andreas L. Opdahl and

2. Outline • Context: UEML and InterOP • Objectives • Template • GRL • Applying the template to GRL • Observations and findings • Summary of contributions • Future work

3. UEML and InterOPwww.interop-noe.org • Enterprise Modelling (EM) • modelling the various aspects of the enterprise • processes, resources, organisational structure, information and information flows, strategy,... • for various purposes • developing supporting IS, simulation, planning, decision making, training,... • support enterprise interoperabilty and integration • Current situation : tower a Babel • many languages, many tools • Consequence : interoperability, integration and shared enterprise knowledge difficult to attain

4. UEML and InterOPwww.interop-noe.org • UEML • Unified Enterprise Modelling Language • An intermediate language that supports • integration and transformation of enterprise models • maintaining global consistency across models and tools • Past: UEML 1.0 (2003, UEML project) • small pilot project • focus on process • integrates 3 EMLs: GRAI [Doumeingts], EEML [Jorgensen&Carlsen] and IEM [Mertins&Jochem] • used ad-hoc DB-inspired integration approach

5. UEML and InterOPwww.interop-noe.org • Present: towards UEML 2.0 • started in 2004 as one of the activities of InterOP NoE • larger and distributed settings • long term iterative and incremental process determine choice of Requirements Languages determine choice andimprovement of integrated through Approaches

6. UEML and InterOPwww.interop-noe.org • Current task • Find out constructs of different languages that are suitable for modelling the same real-world things • Approach: based on template by Opdahl and Henderson-Sellers • Current shortlist of languages being studied:UML 2.0, GRL, XPDL, BPMN, IDEF3,ISO/DIS 19440, Coloured Petri Nets

7. Objectivesof this paper • Report on template-based definition of GRL • 1st iteration • Why GRL ? • Goals are an important aspect of the enterprise • Goal modelling is currently missing in the UEML • GRL integrates i* and NFR • GRL is expected to become popular • GRL has a public specification

8. Template[Opdahl & Henderson-Sellers, 2004] • Purpose • structured text-based way of defining the syntax and semantics of modeling languages • for further analysis, comparison, integration,... • Advantages • distributed work • simple to use • tailorability and extensibility • Limitations • no visualisation, no overall picture

9. Template[Opdahl & Henderson-Sellers, 2004] • Template fields (per modelling construct)(1/2) • Preamble • Construct name • Alternative construct names • Which language the construct is part of • Language acronym and references (URI/other) • Which diagram types the construct is used in • Diagram type acronym and references (URI/other) • Syntax definition • Icon/line style (lexical information) • User-definable attributes • Relationships to other constructs • Same diagram type • Same language, other diagram types • Cardinality restrictions • Layout conventions

10. Template[Opdahl & Henderson-Sellers, 2004] • Template fields (2/2) • Semantics (in terms of BWW-Ontology) • Which instantiation levelis the modelling construct intended to represent? • Which classof things is it intended to represent? • Which propertiesis it intended to represent, if any?Which relationshipsis it intended to represent, if any? • Which states, events and processesis it intended to represent, if any? • Which modality(permission, recommendation etc) is is intended to represent? • Open issues

11. Template[Opdahl & Henderson-Sellers, 2004] Inst level For each construct Modality Segment Represented Class Represented Property Represented state Represented event Ontological state Ontological Class Ontological Property Ontological event Shared ontology

12. GRL 3.0www.usecasemaps.org/urn • Goal-oriented Requirements Language • aka ITU standard URN-NFR • Originates from NFR (Chung) and i* (Yu) • 4 categories of concepts in GRL • Actor • intentional elements • Goal, Softgoal, Task, Resource and Belief • links (intentional relationships) • Dependency, Decomposition, Means-end,Contibution, Correlation • non-intentional elements • references to non-GRL model elements

13. GRL 3.0www.usecasemaps.org/urn • GRL 3.0 specification consists of • 3 concrete syntaxes • textual syntax (in BNF) • graphical syntax (in BNF + topological information) • XML syntax (as an XML DTD) • informal semantics • examples of GRL models • a tutorial • No abstract syntax (meta-model)

14. GRL 3.0www.usecasemaps.org/urn Example(from [Yu])

15. Applying the template to GRLExample: Goal {instance, type} Goal Wished by actorif any Life time isHeldBy hasAttribute isSubElementIn isEndIn represents isDependumOf ”Dependency”0:n ”Attribute”0:n ”Decomposition”0:n ”Means-end”0:n ”Actor” 0:1 ”Goal”1:1 ActiveThing StateLaw AnyRegularProperty TransformationLaw Law Thing Property

16. Applying the template to GRL • Some sample BWW definitions: • “A state law is a law that constrains the values that other properties can have for individual states the thing can be in, i.e., state laws are structural/static.” • “A transformation law is a law that constrains the values that other properties can have across multiple states, i.e., transformation laws are behavioural/dynamic.” • “One thing acts on another thing if and only if the history of the second thing would have been different had the first thing not existed.” • “We say that one thing is acted on by another thing if and only if the second thing acts on the first.”

17. Applying the template to GRLExample: Goal • Some of the issues raised • A Goal is not always held by an Actor ! • whose goal is it if it is not ? • Are Actors humans or can they be other things (computer-systems, organisational units,...)?Specific individuals or classes? Roles ? • Whose properties does the state law constrain? • the future system ? the current system ? the overall organisation ?

18. Applying the template to GRLExample: Goal {instance, type} Goal Wished by actorif any Life time isHeldBy hasAttribute isSubElementIn isEndIn isAbout represents isDependumOf ”Dependency”0:n ”Attribute”0:n ”Decomposition”0:n ”Means-end”0:n ”Actor” 0:1 ”Goal”1:1 ”FutureSystem” 1:1 ActiveThing StateLaw ActedOnThing AnyRegularProperty TransformationLaw Law Thing Property

19. Applying the template to GRLExample: Goal • Some of the issues raised (cont’s) • According to the syntax, Goal can also be the source (depender) or target (dependee) of a Dependency.What does it mean ? • the attainment of that goal depends or is depended on by ‘something’ ? • overlap with the semantics of Contribution and Correlation • what can that ‘something’ be ? • the actor depends on ‘something’ for the attainment of that goal • what if there is no holding actor ? • what can that ‘something’ be ? • ... ?

20. Applying the template to GRLOverview • Filled in template: 2-3 pages per construct

21. Applying the template to GRLOverview

22. Observations and findings • Template-based definition required high degree of subjectivity • essentially because GRL spec is imprecise • Many dark spots in GRL • central constructs without or with vague semantics • e.g. goal, actor, dependency • true of secondary construct too • e.g. « short-hands » • contradictions between the various concrete syntaxes • parts of the syntax are not very intuitive • e.g. DECOMPOSITION <ID> FROM <SUB-EL>TO <COMPOUND-EL> • better: DECOMPOSITION <ID> OF <COMPOUND-EL>INTO <SUB-EL>

23. Observations and findings • Using the template was easy • short tutorial (1h) + examples enough to start • took 4 days to complete • Getting into BWW was harder • but the template helped gain familiarity with BWW • BWW too general to discriminate between GRL constructs • e.g. Goal, Softgoal, Belief and Dependency all have StateLaw as a BWW represented property • informal justifications and open issues in template are as important as represented classes and properties • Many repetitive tasks in filling in the template

24. Summary of contributions • Made abstract syntax (meta-model) of GRL explicit • Made (a tentative) semantic of GRL explicit • Discovered problems in current version of GRL • Discovered limits in current version of template

25. Future work • 2nd iteration • Add new classes and properties to BWW • toward an enterprise-specific version of the ontology • Complete template-based definition of GRL • discuss results with GRL users and ITU to seek consensus • use more specific BWW classes and properties • issues not addressed yet: Contribution and Correlation subtypes in GRL

26. Future work • Complete definitions of other EMLs • Compare definitions of EMLs • Integrate into the UEML • Tool support for template usage • collaborative editing and management of templates • repository • automate comparisons of EMLs • visualisation • import meta-models (if they exist) • ...