Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

DHHT - Modeling beyond plain graphs


Published on

  • Be the first to comment

  • Be the first to like this

DHHT - Modeling beyond plain graphs

  1. 1. Distributed Hierarchical Hyper-TGraphs :Modeling beyond plain graphs Daniel Bildhauer, Jürgen Ebert Institute for Software Technology University of Koblenz-Landau, Germany
  2. 2. Overview• Motivation ➡ Why?• DHHTGraphs ➡ What?• Details ➡ How?• Implementation ➡ Does it work?• Conclusion ➡ Current state and what comes next? 2
  3. 3. jgralab.uni-koblenz.deWhy?
  4. 4. 4
  5. 5. jgralab.uni-koblenz.deSimple graph representation• Symbols are represented by nodes• Lines connecting symbols are represented by edges• But: Some symbols are relation-like and some lines belong together 5
  6. 6. jgralab.uni-koblenz.deIssues of graph representation• Models contain ad modeling profits from: • N-ary relationships • Abstraction and refinement • Distribution• Graphs are a suitable representation of models• Above concepts are not supported by plain graphs• Workarounds & existing solutions not sufficient 6
  7. 7. jgralab.uni-koblenz.deWorkarounds & existing solutions • Workarounds cause extra effort to handle graphs • Relation-like vertices simulate n-ary relations • Marking of elements simulates abstraction levels • Existing extended graph concepts are not sufficient • Many variants of hyperedges, hierarchy and distribution, but no integrated solution • Graph model to restricted or to complex • Not fully implemented/no convenient API 7
  8. 8. jgralab.uni-koblenz.deWhat?
  9. 9. jgralab.uni-koblenz.deDemands to a modern graph framework• Seamless integration of distribution, hierarchy and hyperedges with established graph concepts• Precise and well-defined graph formalism• Ability to specify domain-specific aspects & constraints by graph schemas• Efficient implementation to handle large graphs• Seamless integration in modern software by API 9
  10. 10. Proposal: DHHTGraphs• Distribution of graphs over networks• Hierarchical structuring and refinement • Refinement of elements by nested graphs • Refinement of graphs by visibility layers• Hyperedges with labeled directed ends• Typing and attribution of vertices and edges• Ordering of incidences at vertices and edges• Compatibel to existing concepts as far as possible 10
  11. 11. jgralab.uni-koblenz.deHow?
  12. 12. Hypergraphs v2: Feature• Typing, attribution and v1: BusinessProcess name=“pay order“ name=“payment method“ ordering of vertices and edges [1] [1]• Connection by labeled, i1: realizedProcess {1} i3: realizedFeature directed & ordered incidences {2} traversable in both directions e1: FeatureTraceability Link• Equality and duality of vertices id=4711 {3} and edges {4} i2: usedRule i4: target• Vertices represent entities, [1] [1] edges their relationships v3: TransformationRule v4: Activity name=“pay order“ 12
  13. 13. jgralab.uni-koblenz.deMetamodeling Hypergraphs• Modeling language grUML TransformationRule source ModelElement (graph UML) name: String 0..* name: String 0..1 0..* 0..* usedRule• Vertex- and Edge classes define TraceabilityLink 0..* target types and attributes #vertices per edge 0..* id: int #edges per vertex• Incidence classes define Activity labeled connections Feature• Specialization of vertex-, realizedProcess subsets source 0..* TraceabilityLink 0..* realizedFeature subsets source edge-, and incidence classes 0..* 0..* ModelElement ModelElement• Multiplicities and incidence BusinessProcess Feature inheritance for vertex- and edge classes 13
  14. 14. Hierarchical graphs v6: TransformationRule• Element refinement by tree-like nesting of graphs in elements i5: usedRule i7: usedRule • Connections across boundaries e1: e2: • Border of nested graphs are of same kind as nested elements FeatureTraceability Link FeatureTraceability Link• Graph refinement by visibility layers i8: target i9: target for elements v4: Activity• Refinements are DHHTGraphs on name=“pay order“ their own v5: Activity name=“enter credit card details“ 14
  15. 15. Metamodeling hierarchy <<nested>>• Compositions define possible TraceabilityLink nesting relationships id: int target • Tree-like on instance level ModelElement constraints • Stereotyped compositions {kappa=0..4} define edge nesting • 0..* ActivityNode Compositions also define edge classes (compatibility to partOf classical graph technology) 0..1• Allowed visibility indicated by Activity Branch constraints (kappa) 15
  16. 16. Distributed graphs v2: Feature• Partitioning and distribution v1: BusinessProcess name=“pay order“ name=“payment method“ across several stations• Treatment of local and global realizedProcess realizedFeature graphs in the same way e1:• Compatibility to hierarchy FeatureTraceability Link id=4711• Distributed graphs are full usedRule target DHHTGraphs with support of distribution and hierarchy• No domain specific features, v3: TransformationRule v4: Activity name=“pay order“ thus no metamodeling 16
  17. 17. jgralab.uni-koblenz.deDoes it work?
  18. 18. Implementation• Extension of Java library JGraLab for plain TGraphs• Typing, attribution... realized by native Java constructs• Extended symmetric incidence lists as datastructure• Distribution by Java Remote Method Invocation, efficient access by element-ids identify machine• In-memory storage • 1GB: 106 vertices, 106 edges, 5x106 incidences (creation 7s) • Breadth first search on that graph in 2,5s on 2,3GHz 18
  19. 19. TraceabilityLink id: int API ModelElement ModelElement BusinessProcess Feature 0..* 0..* process Feature feature subsets source TraceabilityLink subsets source 0..* 0..*• Object-oriented access to all via KM3-like DSL tg DHHTGraph properties public interface TraceabilityLink extends Edge {• Equal treatment of complete public int get_id(); graphs and all subgraphs public void set_id(int _id); public TraceabilityLink getNextTraceabilityLink();• Seamless integration in public TraceabilityLink_source getFirst_source(); applications by generated public TraceabilityLink_rule getFirst_rule(); } schema-specific API (interface+implementation) public interface FeatureTraceabilityLink extends TraceabilityLink { public FeatureTraceabilityLink getNextFeatureTraceabilityLink(); public FeatureTraceabilityLink_process getFirst_process(); public FeatureTraceabilityLink_activity getFirst_activity(); } 19
  20. 20. Current state &what comes next?
  21. 21. Main design decisions• Vertices and edges are dual • Vertices represent entities, edges their relations• Distribution and hierarchy are compatible • Subgraphs are DHHTGraphs on their own• Nested vertices and edges have only vertices or edges on their border, respectively• Seamless from definition to implementation 21
  22. 22. The future: Querying DHHTGraphs• Based on existing TGraph query language GReQL from process:V{Process} with process (-->{FeatureTraceabilityLink_process} <--{TraceabiliyLink_rule})+ & {TransformationRule @“MyRule“} report process -->{FeatureTraceabilityLink} end 22
  23. 23. Conclusion• Seamless realization of • Hyperedges with labeled ends • Nesting of graphs in elements • Abstraction levels by visibility layers • Distribution• Based on formal mathematical definition• Metamodeling of domain-specific aspects• Efficient implementation & convenient APIs• Available soon at under GPL 23
  24. 24. jgralab.uni-koblenz.deThanks for your attention!Any questions?