September, 13th, 2009

1. MPM (october, due august): RAM process and Higher-order transformation
2. SIMUTools (march, due october): Modelling a distributed DEVS simulator as a DEVS model with fault-tolerance capabilities
3. Research proposal exam (november)
4. GT-VMT (march, due december): T-Core and primitive transformation languages
5. ICMT (july, due january): MoTif-Core from T-Core and Exceptional transformations
6. ICMT (july, due january): Parallelizability of model transformation patterns and Precise semantics of parallelism in MoTif
7. Transactions of SCS (december): Simulating a distributed DEVS simulator with optimal partitioning and fault-tolerance
8. Research visit in Antwerp (may...)

January, 23rd, 2009

1. Comprehensive exam post-mortem: final document.
2. PADS submission.
3. Extension of modelled distributed DEVS simulator to MoTif transformation.
4. -> Case study of CD2RDBMS.
5. NII or DAAD (latter only for undergraduates).

Novembre, 14th, 2008

Having successfully modelled an AtomicSolver, a Coordinator and a RootCoordinator as atomic DEVS models, we have discussed how a distributed environment can further be modelled. This involves having: Local Coupling Table (for local port mappings), Remote Coupling Table (for remote port mappings over the network), Model Repository Server (where the model to simulate lies), Log Server (keeping a trace of events processed and transitions performed), Live Server (checking which node is in failure), Save Server (where the state of each simulator is saved) and a "God" Server which initializes the simulation. We have also identified what possible fault-tolerance statistics can be collected from simulating such an environment. For example, performance versus time-out because often the Coordinator does not know how long it should wait before time-out assuming its influencee failed. Thus, in the real distributed DEVS, it can simulate the possible scenarios with different time-outs and figure out which one is a better choice.

A distributed version of MoTif is desired when, in the presence of a Selector, at most one of rules R1 & R2 must be applied. Another case is when threads of transformation are run in parallel and later synchronized by a Synchronizer. Suppose the first thread consists of R1 and the second of R2. R1 & R2 better be parallel independent. How to check that? Several approaches may be considered:

1. Run a conservative static critical pair analysis on the structures present in the rules: check that LHS(R1) n RHS(R2) = 0 and LHS(R2) n RHS(R1) = 0 (of course taking in consideration NACs). But this is only a sufficient condition because it can give a false positive answer.
2. A more thorough check for parallel independence can be done through full exploration/simulation of R1 and R2, considering the constraints (evaluable at run-time).
3. A third alternative is to effectively do a full dynamic check and if a conflict is detected, the modeller can specify a block for handling this conflict. This is analogous to handling exceptions in programming languages, but in this case, the "throw" of exception is modelled to trigger the "catch" model that handles such a parallel independence conflict.

An advantage of distributing DEVS for model transformation is interoperability. DEVS can serve as a "bus" or middleware where the transformation of a model can be scaled onto different transformation tools. Providing a (2-way) adapter for each tool, the transformation can flow in a MoTif model, be then fed to another tool after which the transformation continues within MoTif... A chain (in the form of a control flow) of transformation "packages" can be constructed as such, taking advantage of each tool to what it is best for. This can be done using a distributed DEVS as a foundation for the transformation cycle.

October, 24th, 2008

1. SoSym: MoTif
2. Transactions of SCS: GPSS + PiDemos (HV associated ed.)
3. JCCBS or MoDELS: Security (January)
4. ICMT: MM of MT & HOT -> Jeff Gray (January)

July, 22nd, 2008

1. P0: back-link to AToM³
2. P1: Kernel, Efficiency
3. P1.5: "Regular Expressions" for Patterns
4. P2: Distributed
5. P2.5: Hierarchy

• Triple Rules
• Declarative Composition ~ Algebraic relations between attributes
• Database Implementation
• Higher-Order Transformations

• MoDELS, ICMT, GT-VMT
• SoSym, SCP, TSE, SP&E
• TOMACS, T. Simulation, SIMPRA

October, 19th 2007

1. GHOST++
   Modify the graph grammar to have a smarter ghost

2. ta (g)
   Use time as a metric. The metric will be the "time to live"

3. TRACE++
   Pass along the graph instead of the rules.

   Two ports are needed:

   • 1. Send the graph after a rewrite
   • 2. Query the current state (graph)
   We need an external API of helper query methods on the graph.
   Whenever the user sees a change, try to react with delay

4. USER++
   Have different user levels: random, smart, fast, slow ... user

5. Real-Time
   Using R-T DEVS, user reaction time delayed for

   • 1. Hitting the button
   • 2. Reaction to change of graph configuration

6. User Interface
   Stand-alone python (pydevs) code + static SVG + code to link. See with Jake.

Build table of performance by changing the parameters for the simulation

The main disadvantage of our approach is that DEVS makes a copy of each graph before it is sent to a block: Inefficient.

October, 3rd 2007

Our MOF should be something like Ecore, which is typed by Ecore.
But the meta-model should include:

• classes
• actions
• constraints

Ecore must be implemented in Himesis.
And Himesis will be designed in class diagrams (but this is on the side).

September, 7th 2007

1. Build a Progrmammed Graph Rewriting Control Flow modelling environment based on DEvS. -- Done.

2. Meta-model the TGG formalism and build a graph grammar that transforms a TGG into a traditional GG. First a single TGG, then a flow of TGGs into a GRCF model.
   Publish a paper in GT-VMT on that. The contribution is on the way of linking the different GGRules that represent a TGG.

3. AToM³ revised.
   Each Meta-model should be mapped on an Abstract Syntax Hierarchical Graph (ASHG). This ASHG must then be compiled into a Himesis model.
   So there needs to be a disucussion on what this ASHG will be (class diagrams, with constraints, action language, ...).

4. Optimize the matching (interpretted //vs// compiled), of course using the "very efficient" Himesis matching algorithm.

July, 3rd 2007

1. Based on the DEVS graph rewriting project (COMP 522), automate the translation of AToM³ rules to the python code in the DEVS blocks.
   The code generation can be naïve.
   Add a pivot to input and output of each GG rule: pass the node where the match has succeeded, otherwise pass None.

2. Build the GRCF (Graph Rewriting Control Flow) in the AToM³ environment.
   Construct the Meta-Model and its modelling environment.
   The model only contains atomic and coupled devs blocks for rules. No user, no controller.

3. Think about an eventual Kiltera paper.

4. Generate everything in Himesis (instead of ASG): first by hand, then automatically.
   Refer to Philippe Nguyen's work.

5. Optimize the matching (interpretted //vs// compiled), of course using the "very efficient" Himesis matching algorithm.

6. Replace the GG rules (traditional graph grammar rules) by TGR rules (Triple Graph Rewriting rules).
   This is a GG rule whose LHS and RHS are Triple Graphs.

7. Integrate pure Triple graph grammars (at the Meta-Model level, Schür's way).
   Investigate automatic transformations from TGG -> TGR R.
   Don't neglect the declarative attribute relations...

March, 23rd 2007
-- revised April, 13th 2007

• piDemos + GG => operational semantics (updates the state of pidemos model, stays within piDemos)
  nice visual animation of the behaviour
  => with very little effort, map to GPSS. GG rules are almost 1-1 (seize, release, ...)
  done by syntax mapping, the behaviour is the same!
  - no interrupt in pidemos
  + pidemos can now be used professionally
  

• pidemos compilation to ML => compare trace of GG, of Birtwisle simulator, of GPSS simulator results

• piDemos language is a subset of the GPSS language.

• Contribution: pidemos --GG--> pidemos: animation aspect of a simulated model.
  - experimient with (already existing) languages
  - immmediate animation, simulation
  - map onto code => in no time have a visual editor for pidemos
  Related work: reading about GG's, GG tools, what was done with pidemos & gpss, simulation tools
  Intro: GG, piDemos, GPSS
  Developpment: describe these GG tranformation and how they work (example of the way bridge, used in the pidemos paper)
  Graph Rewriting + MM: behind the back of my MM, I add attributes to my model:
     - augment MM with extra-attributes (ex: hasBeenVisited, ...)
     - modeler point of view: only used for the GG execution, not kept in saved model -> transformation side

March, 9th 2007

February, 1st 2007

• PROGRES

  1. Description and download at http://www-i3.informatik.rwth-aachen.de/tikiwiki/tiki-index.php?page_ref_id=213

• GReAT

  1. Graph Transformations on Domain-Specific Models
  2. GReAT a solution for the MIC bottleneck
  3. Metamodel Based Model Transformation Language
  4. The Design of a Language for Model Transformations

• AGG

  1. Description at http://tfs.cs.tu-berlin.de/agg/docu.html

• VIATRA

  1. VIATRA for Formal Verification and Validation of UML Models
  2. Automated Generation in VIATRA
  3. Metamodel Based Model Transformation Language
  4. Download at http://dev.eclipse.org/viewcvs/indextech.cgi/gmt-home/subprojects/VIATRA2/index.html

• Model Transformation by Graph Transformation: A Comparative Study

November, 16th 2006
-- revised February, 1st 2007

• COMP 522: Graph Transformation in DEVS

  1. Read Marc Provost's thesis Himesis
     * Chapters 2 and 5.
  2. Integrate Graph Transformations in DEVS: naively code rules by hand. Application: PiDemos.

• COMP 762: Programmed Graph Rewriting

  1. Deep reading into PROGRES and GReAT
     Find an exhaustive list that completes AGG, VMTS, VIATRA, ...
  2. Continue further the work done in 522.

• COMP 601: TGG and QVT

  1. Read Marc Provost's thesis Himesis.
  2. Read the TGG article by Olivier Rohe Model Transformation by Interpreting Triple Graph Grammars: Evaluation and Case Study..
  3. Read Joel Greenyer's thesis Reconciling TGGs with QVT
     

September, 22nd 2006

• A thesis is divided in 4 parts:

  1. Reading:
     This is the part where you talk about what already exists in the litterature, what work has already been done. It is to give the background of what we have until now and put in the context.
  2. Focus:
     This is the part where you show what you have done but theoretically speeking. All the formal explanations, definitions, ... are to be mentionned here.
  3. Implementation:
     This is the part where you show what you have done but practically speeking. What you have built, showing snapshots and explanations.
  4. Case Study:
     This is the part where you show that what you have done actually works! That it is useful. You do so by applying your theory + implementation in a real-life example.

• The easiest way to write a thesis is by attacking the problem in a Divide-and-Conquer approach. You divide each part by asking questions. Then each question will be divided into sub-questions. That until you reach question where the answer is simple. Then you construct your thesis by merging all these Q&A's in an organized and logical way.
  Bear in mind that the hardest part in a thesis is to find the right questions.