Me2011 presentation by Manfred Jeusfeld

A Deductive View on Process-Data Diagrams Manfred Jeusfeld Tilburg University, TiSEM/IM The Netherlands [email_address] created: 4-Apr-2011 revised: 17-Apr-2011

The goal Understand to which extent deductive rules can formalize PDDs and their support the modeling process with PDDs The approach Use MOF-like abstraction hierarchies to represent the PDD constructs. Use the deductive rule language of ConceptBase to formalize the re-combination of PDD fragments

distinguish correct (desired) from incorrect (undesired) PDDs

provide a simple facility for traceability

The “MOF” levels (also known from IRDS) in Constructs to define constructs of modeling languages Constructs of modeling languages Models Data, traces of some reality in in

Instantiation rule Employee Project worksOn 1..* 2..* M1: Class level M0: Instance level mary:Employee p1:Project in bill:Employee worksOn worksOn in The instances must conform to the schema of their classes

Running example (by I. vd Weerd) process part= the workflow on the left side of a PDD product part= the data/deliverable specs on the right side of the PDD Extensive requirements elicitation Goal- setting Describe background List features List assumptions Describe goals Describe scope Domain modeling Define important terms Identify relations Draw class diagram Use case modeling Describe actors Extract use cases Draw use case model ... REQUIREMENTS DOC GOAL SETTING GOAL SETTING BACKGROUND FEATURE LIST ASSUMPTIONS GOAL LIST SCOPE GOAL SETTING DOMAIN MODEL TERM RELATION RELATION CLASS DIAGRAM ACTOR USE CASE GOAL SETTING USE CASE MODEL

So what MOF level is applicable for PDDs? in mary 2011-04-21 10:21 enrolls M0 M1 M1 M2 The process part of PDDs is typically one MOF level below the product part! Draw class diagram CLASS DIAGRAM Drawing my first C.D. University Diagram Student Course

M3 level for PDDs Deliverable is both M2 and M3; hence we can use the 'produces' link for on the process part at M2; while still allowing that Deliverable is essentially an M3 construct (having for example Class Diagram as instance) produces NodeOrLink ProcessElem ProductElem Deliverable isA isA isA in Activity in

Embed the process & product elements into MOF levels M3 M2 M1 M0 PDD Notation PDD models, e.g. Use Case Modeling PDD Execution NodeOrLink “ Activity UC1 produce use case model X” “ Usecase modeling produces...” “ An activity produces models” M3 M2 M1 M0 Deliverable OpenConcept, Model Domain Model, Use case model Usecase model X real data and processes produces

ActivityNode in Node,ProcessElem with connectedTo next: ActivityNode end ActivityDiagram in Model,Class isA Activity with contains activity: ActivityNode; control: ActivityNode!next end Phase in Model isA ActivityDiagram end PDD in Model isA Phase end PDDLibrary in Model isA PDD end Agent in connectedTo end Activity in ProcessElem isA ActivityNode with connectedTo produces: Deliverable; performer: Agent end ParallelBranch in ProcessElem isA Activity with connectedTo branch: ActivityNode end ParallelBranch!branch isA ActivityNode!next end ParallelJoin in Node isA Activity end DecisionPoint in ProcessElem isA Activity with connectedTo choice: ActivityNode end DecisionPoint!choice isA ActivityNode!next end DecisionJoin in Node isA Activity end The process part of PDDs So, this is basically a subset of UML activity diagrams ...

Deliverable in ProductElem isA ProductElem end Concept isA Deliverable end StandardConcept isA Concept end OpenConcept isA Concept ,Model with attribute contains: Deliverable end ClosedConcept isA Concept ,Model end DocumentDeliverable isA OpenConcept end ModelDeliverable isA OpenConcept end The product part of PDDs Terminology can be adpated/extended

The concept 'Model' is pre-defined in the M3 level of the first part of this talk. We re-use it here for our purposes

Activity in Class with rule d1: $ forall a1/ClosedActivity a2/ComplexActivity s/ActivityNode (a1 next a2) and (s in StartNode[a2]) ==> (a1 next s) $; d2: $ forall a1/ComplexActivity a2/ClosedActivity e/ActivityNode (a1 next a2) and (e in EndNode[a1]) ==> (e next a2) $; d3: $ forall a1,a2/ComplexActivity e,s/ActivityNode (a1 next a2) and (e in EndNode[a1]) and (s in StartNode[a2]) ==> (e next s) $ end Defining the re-combination of PDD fragments Stating (a1 next a2) means that the end node of fragment a1 is connected the start node of a2

Example re-combination domain modeling is positioned after the activity goal setting, hence 'describe scope' is followed by 'define important terms'. if the sub-activities are themselves complex then the re-combination rule is applied to the parts as well The 3 deductive rules d1,d2,d3 of 'Activity' completely specify the re-combination feature!

Export small PDD fragment from ConceptBase

Export the PDD of the running example ConceptBase exports the PDD to the DOT format of the graph layout tool GraphViz. The export rules assign a light grey color to deliverables that are not part of the main deliverable 'Requirements Document'. Here, REQUIREMENTS REVIEW REPORT is an example of such a deliverable

Me2011 presentation by Manfred Jeusfeld

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to Me2011 presentation by Manfred Jeusfeld (20)

More from Method Engineering 2011 - IFIP WG.8.1 Working Conference (18)

Recently uploaded (20)

Me2011 presentation by Manfred Jeusfeld

Editor's Notes