Me2011 presentation by Manfred Jeusfeld

671 views
613 views

Published on

A Deductive View on Process-Data Diagrams

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
671
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 1 1 1 1 1 1
  • 22 22 16 16 16
  • Me2011 presentation by Manfred Jeusfeld

    1. 1. 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
    2. 2. 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 <ul><ul><li>formalize the re-combination of PDD fragments
    3. 3. distinguish correct (desired) from incorrect (undesired) PDDs
    4. 4. provide a simple facility for traceability </li></ul></ul>
    5. 5. 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
    6. 6. Instantiation rule Employee Project worksOn 1..* 2..* M1: Class level M0: Instance level mary:Employee p1:Project in bill:Employee worksOn worksOn in <ul><li>The instances must conform to the schema of their classes </li></ul>
    7. 7. 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
    8. 8. 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
    9. 9. M3 level for PDDs <ul><li>Deliverable is both M2 and M3; hence we can use the 'produces' link </li></ul>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
    10. 10. 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
    11. 11. 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 ...
    12. 12. 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 <ul><li>Terminology can be adpated/extended
    13. 13. The concept 'Model' is pre-defined in the M3 level of the </li></ul>first part of this talk. We re-use it here for our purposes
    14. 14. 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 <ul><li>Stating (a1 next a2) means that the end node of fragment </li></ul>a1 is connected the start node of a2
    15. 15. Example re-combination <ul><li>domain modeling is </li></ul>positioned after the activity goal setting, hence 'describe scope' is followed by 'define important terms'. <ul><li>if the sub-activities </li></ul>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!
    16. 16. Export small PDD fragment from ConceptBase
    17. 17. Export the PDD of the running example <ul><li>ConceptBase exports the </li></ul>PDD to the DOT format of the graph layout tool GraphViz. <ul><li>The export rules assign a light grey </li></ul>color to deliverables that are not part of the main deliverable 'Requirements Document'. Here, REQUIREMENTS REVIEW REPORT is an example of such a deliverable
    18. 18. forall d1,d2/DeliverableInstance a/ActivityInstance (a [retrieves] d1) and (a [produces] d2) ==> (d2 depOnDirectly d1) forall d1,d2,d3/DeliverableInstance (d1 depOnDirectly d2) and (d2 depOn d3) ==> (d1 depOn d3) Traceability M0: PDD Traces M1: PDD Libs M2: PDD Notation M1 M2 M3
    19. 19. Demo...
    20. 20. Summary <ul><li>PDD formalization with Datalog </li></ul><ul><li>semantics of PDD re-combination via deductive rules </li></ul><ul><li>traceability and analysis services </li></ul>More: http://conceptbase.cc

    ×