DHHTGraphs - Modeling beyond plain graphs
Upcoming SlideShare
Loading in...5

DHHTGraphs - Modeling beyond plain graphs



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 ...

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



Total Views
Slideshare-icon Views on SlideShare
Embed Views



4 Embeds 346

http://www.graph-database.org 342
http://translate.googleusercontent.com 2
http://www.onlydoo.com 1
https://twitter.com 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    DHHTGraphs - Modeling beyond plain graphs DHHTGraphs - Modeling beyond plain graphs Presentation Transcript

    • 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
    • jgralab.uni-koblenz.de Overview• Motivation ➡ Why?• DHHTGraphs ➡ What?• Details ➡ How?• Implementation ➡ Does it work?• Conclusion ➡ Current state and what comes next? 2
    • jgralab.uni-koblenz.deWhy?
    • jgralab.uni-koblenz.de 4
    • 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
    • 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
    • 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
    • jgralab.uni-koblenz.deWhat?
    • 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
    • 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
    • jgralab.uni-koblenz.deHow?
    • 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
    • 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
    • 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
    • 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
    • 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
    • jgralab.uni-koblenz.deDoes it work?
    • 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
    • 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
    • jgralab.uni-koblenz.de Current state &what comes next?
    • 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
    • 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
    • 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
    • jgralab.uni-koblenz.deThanks for your attention!Any questions?