Distributed Hierarchical Hyper-TGraphs (DHHTGraphs) offer distribution of graphs over networks, refinement of graph elements by nested graphs, refinement of complete graphs by visibility levels and some

1. Distributed Hierarchical
Hyper-TGraphs :
Modeling beyond plain graphs
Daniel Bildhauer, Jürgen Ebert
Institute for Software Technology
University of Koblenz-Landau, Germany
dbildh@uni-koblenz.de
jgralab.uni-koblenz.de

2. jgralab.uni-koblenz.de
Overview
• Motivation ➡ Why?
• DHHTGraphs ➡ What?
• Details ➡ How?
• Implementation ➡ Does it work?
• Conclusion ➡ Current state and
what comes next?
2

3. jgralab.uni-koblenz.de
Why?

4. jgralab.uni-koblenz.de
4

5. jgralab.uni-koblenz.de
Simple 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. jgralab.uni-koblenz.de
Issues 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. jgralab.uni-koblenz.de
Workarounds & 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. jgralab.uni-koblenz.de
What?

9. jgralab.uni-koblenz.de
Demands 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. jgralab.uni-koblenz.de
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. jgralab.uni-koblenz.de
How?

12. jgralab.uni-koblenz.de
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. jgralab.uni-koblenz.de
Metamodeling 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. jgralab.uni-koblenz.de
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. jgralab.uni-koblenz.de
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. jgralab.uni-koblenz.de
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. jgralab.uni-koblenz.de
Does it work?

18. jgralab.uni-koblenz.de
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. jgralab.uni-koblenz.de
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. jgralab.uni-koblenz.de
Current state &
what comes next?

21. jgralab.uni-koblenz.de
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. jgralab.uni-koblenz.de
The future: Querying
DHHTGraphs
• Based on existing TGraph query language GReQL
from process:V{Process}
with process (-->{FeatureTraceabilityLink_process}
<--{TraceabiliyLink_rule})+
& {TransformationRule @
thisVertex.name=“MyRule“}
report process -->{FeatureTraceabilityLink} end
22

23. jgralab.uni-koblenz.de
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 jgralab.uni-koblenz.de under GPL
23

24. jgralab.uni-koblenz.de
Thanks for your
attention!
Any questions?