Plan

Home
Plan
Publications
Deliverables
Wish List
Canada
Links

Edit

Go to [current] week.

Week 1

+ Meeting new colleages, getting to know people, setting up my new working environment..

+ Discuss with prof. H. Vangheluwe my work at MSDL lab.

+ Come up with a research plan for my stay at McGill and eventual deliverables.

+ Preparations for the SCSC 2003 conference.

Week 2

+ Attending the SCSC 2003 conference. Click here to view my presentation.

+ Set up my website (you are visiting it right now).

+ Finish and document My Little ZProject.

Week 3

+ Study the work of J. de Lara and H. Vangheluwe on their AToM3-generated Process Interaction environment.

+ SCSC'2003 follow-up contacts (Model Library, - DFD to UML transformations, Marine guy from NL, HASE, - Meta Calculus)

+ Model POKer's Initial System (view on the resources and processes) in Juan's PI notation.

+ Model POKer's Operational Semantics in the Graph Grammar formalism (15% done):

  • [~99%] newP (copied from Juan's generatePiece rule)
  • [~90%] close
  • [~90%] newR

PS: This week ended bad.

Week 4

A Lesson:

The Juan's PI MM implicitly includes a construct that corresponds to an efficient data structure (list) used in conventional programming languages. Expressing visually operational semantics of operations with the list (as a part of o.s. of my POKer commands) proved a major task, as number of special cases of the same rule was growing as function of 2 in power N, where 2 corresponds to 2 possible states of a queue (empty and not empty) and N to the number of queues in a search pattern (LHS).

Solution: completely remove o.s. associated with complex and inneficient (visualy-wise) data structures into separate rules. Now, back to re-writing my GG rules.

+ Add new entity to the PI metamodel to explicitly represent mapping data structure, along with the existing sequence structure (this is the immidiate follow-up to the lesson above):

  • MachineMapping

Note:

Now efficient data structures (MachineMapping and Machine Queue) are explicitly present in the metamodel. However their type is still implicit. Without adding redundant constructs to the metamodel, a solution might be to annotate entities that are datastructures and using the upcoming type checking mechanism of Mark Provorst, lookup their types. For now, I hardcode the type information on the right entities (which is a hack).

+ Add new relationships to the PI metamodel:

  • manageElement (for sequences)
  • manageItem (for mappings)
  • has (for mappings)

These relationships represent managing objects (add, delete) in the context of two efficient data structures: sequences and mappings.

This is related to deducing an efficient data-structure from a metamodel, e.g. PI MM.

Note:

Constraints in metamodel are responsible for so-called static semantics (i.e. how contsructs can be combined to build new constructs). Since I explicitly model semantics (both static and dynemic) in my GG model and human users are not intented to use this PI formalism, I can relax constraints in my metamodel and thus make easier my design process.

+ Implement GG rules that specify operational semantics of methods managing Items and Elements:

  • [100%] appendElement
  • [100%] appendFirstElement (a special case of an empty queue)
  • [100%] sortElements (swap two neigbours) - finally :)))
  • [100%] popElement
  • [100%] popLastElement (a special case of the 1 element queue )
  • [100%] updateItemInit
  • [100%] updateItem (a special case of non-empty mapping; it has purely visual meaning)
  • [100%] deleteItem

+ Continue to model POKer's Operational Semantics in the Graph Grammar formalism:

  • [100%] removeProcess (new method, it should be private)
  • [100%] importProcess (removed o.s. of the queue)
  • [100%] newR
  • [100%] getR
  • [100%] hold (simulation mode)
  • [100%] useResource (variety of hold in case of controller mode)
  • [100%] releaseResource (ends useResource)
  • [100%] putR
  • [100%] blockProcess (variety of getR in case of busy resource)
  • [100%] promoteProcess (undo blockProcess)
  • [100%] main (order of GG rules)

+ Email electronic version of my SCSC'2003 paper to M.Max.

Week 5

+ Fine tune the POKer model:

  • time advance to take into account time of the current process
  • PI events (as defined in piDemos) should be triggred at correct times
  • finalize the order of GG rules

~ (SKIPPED) Make nicer visuals for GG rules. NOTE: Move Entities option in GRS, to position entities in RHS relative to objects in LHS. This should illiminate manual possitioning of entities in GG rule's side effectin (section "Visuals" in rule's Action)

+ Update PI metamodel:

  • relax cardinality constraints on some relationships
  • introduced Declaration space and PieceDeclaration entities
  • added global attributes:
    • min_hold_time
    • max_hold_time
    • max_actions_num
    • mix_actions_num
    • min_delta_time
    • max_delta_time

+ Make demos:

  • Generate multiple Resources
  • Generate multiple Processes
  • N Processes, N Resources
  • Weigbridge access program by Birtwistle and Tofts

+ If time permits, extend POKer's o.s. model with low-priority rules:

  • [ ~100%] decP
  • [ ~100%] newP
  • [ ~100%] close

+ Verify POKer operational semantics against piDemos operational semantics.

Week 6 and 7

+ Read about behaviour verification with help of Sequence Diagrams.

+ Document (briefly) the POKer model.

+ Draft a transformation from the operational semantics GG model to SCD in the Graph Grammar formalism.

Note on specifying behaviour of GG rules conditions and attribute soecifications in LHS and RHS:

  • conditions to be specified in OCL
  • attribute values - in OCL with Side Effects

~ If time permits, add debugging (output) trace to the Process and POKer

~ If time permits, add error handling to POKer

+ Analyze shortcomings of my SCD Metamodel.

Week8

+ Tweak SCD Types:

  • Revise list of parameter types.
  • Fine-tune SCDAttributeType.
  • Fine-tune SCDMethodType.

+ Update SCD Metamodel:

  • Extend list of stereotypes with more predifined values.
  • Make no direct editing option work (bug under Windows?)

+ Adapt Ernesto's DEVS_ER_mdl to NCSE case; it is directly usable as metamodel under AToM3 as it is in ER formalism. Note: I added select for now. Future changes might include consolidating state entity with atomicDEVS for sake of simplicity.

+ Make ER to SCD transformation to be able to transform DEVS_ER_mdl into a SCD model; this diagram containts software models of AtomicDEVS and CoupledDEVS components.

Week 9

+ Fix bug with bad Association connections resulting from any co-existance with an ER model in AToM3. Solution: save and reload the affected model.

Note: the bug shows itself when ER and SCD metamodels are loaded into AToM3 (model, LHS or RHS) at the same time. After a discussion with Ernesto, I suspect that the bug is due to a naming conflict between ER and SCD.

+ Update the Zope Product Generation transformation:

+ synchronize syntax of SCD elements with pyComposer (e.g. parameter type should not appear in code);

+ verify that multiple whole classes are handled correctly;

~ Q: Is it possible to recognise the subject of the last graphical event (e.g. Select) from within a transformation? A: Yes, the following code is placed in a constrain of an entity (in metamodel) and will visually highlight an entity on event DRAG (SELECT does not work) and append a temporary attribute isSelected to object.graphObject_ :

        '#
         # It is a fake constraints used as a placeholder for my visual handling
         #
         if hasattr(self.graphObject_, "isSelected"):
             del self.graphObject_.isSelected
             self.graphObject_.HighLight(0)
             self.graphObject_.DrawObject(self.graphObject_.dc)
             print "deselect"
         else:
             self.graphObject_.isSelected = 1
             self.graphObject_.HighLight(1)  
             print "select"
'

+ From SCD models generate ZProducts.

+ Complete Registration for ESS'2003.

+ Meeting with Hans at 18:30: discussion of my ESS paper.

+ September 15: Camera-Ready Paper deadline for ESS'2003 in Delft

Week 10

+ Modelling custom data types: Solved "Text" bug, by copying "ATOM3Text" module into "Text" module, and renaming "ATOM3Text" class "Text" in the new module. One final touch is importing "ATOM3Text" from "ATOM3Text" in the beginning of the python file with name that looks like a product of leaf types from your custom type model. (In the same file, one can re-implement method toString() to change default string representation of the new data type - very convenient if one plans to use signatures)

+ Update SCD_ER:

  • New SCDAssociations are of none kind by default
  • SCDAssociation is feature-wise an Association Class now (even though we preserve the old name)

~ If time permits, reimplement SCDClass's appearence:

  • if either of attributes or methods section is empty, don't show it;
  • adapt the boundry of a section to its contents;
  • attribute of abstract classes should appear in italic face;
  • attribute should be invisible if stereotype value is 'none';

+ Add global attributes and constraints: it is redundant as SCD models won't be used as metamodels in ATOM3.

+ Explicitly model DEVS2DEVS_GG: changes the DEVS_SCD:

  • Add roles states, ports, children and parent as implicite features.
  • Factor out transitions into an explicit classes.
  • Factor out channel into an explicit class.

    Note: there are 3 types of relationships that are represented with different aggregation kinds in SCD:

    • containment (aggregate, composite) denotes allowed types of children. Containment is similar to generative feature
    • strong composition (composite) means that its must coexist part with its whole, and part must have fixed names unique only within the scope of their parent. They are similar to regular features.
    • reference (none)

+ Explicitly model SCD2ZSCD_GG: prepares any SCD model for ZProduct Code generation:

  • Replace containment roles with respective methods on corresponding classes. Provide implementation of methods in Zope API.
  • Replace reference roles with respective attributes on corresponding classes.
  • Remove associations that represent references (Zope does not need them, only containment is important)
  • Merge equivalent associations.

~ Model Genereating Interfaces:

  • look up implementations of Zope Interfaces for useful paterns
  • The resulted code should be Page Template.
  • Use TypeTT models for data types
  • Use SCD_ER for DEVS objects
  • Data types should be represented with a string?
  • Objects should be represented with a page?

~ Update SCD2ZProduc_GG:

  • Use external files to view and edit DEVS objects. These files to be generated with TypesMM2HTML_GG.

    index_html = HTMLFile("www/SCDClassInterface")

  • if <ProductName>_icon exist, copy it into img/
  • factor out importing classes from rule LocateImmidiateParent into importClasses.
  • If time permits, extend my ZProduct model to include property sheets

    Questions:

    • How to represent features?
    • How to edit features (via separate views?)
    • How to contain programatically?

    Note for ZProduct constructors:

    Object who are parts in composite associations (e.g. state, port), have their ids same as their names. Object who are wholes in composite associations (e.g. atomic devs), have their ids automatically generated.

~ Test new components

~ If time permits, extend SCD with Simplified Sequence Diagrams. Note: I decided to NOT implement this feature, but described how Sequence Diagrams could be used together with Class diagrams to describe and make protocols, make consistency check between class and object, class' feature and object's feature; and verify that generated code (at some point) is valid (test against sequence diagrams).

+ If time permits, model Code Generation 2 PythonDEVS. Note: since I am reusing Ernesto's DEVS metamodel, I can use his Code Generation for PythonDEVS. This is a nice but not necessary feature, which I luckily don't have to implement myself.

+ Write it up (see my ESS'2003 paper)

Week 11 and 12

+ Q: How to access an LHS from an LHS of the GG being applied to the first LHS? A: self.rewritingSystem.graph

+ Model GGrule2Parameters_GG (merged with in GG2SCD_GG_mdl)

+ Model GGrule2SCD_GG (merged with in GG2SCD_GG_mdl)

+ Model GG2SCD_GG_mdl:

Initial Action:

  • acquire the name of the GG, this rule belongs to; save it in global var. GGName
  • acquire the name of the current GG rule, and save it in global var. ruleName
  • check if there is an SCDClass with name . If not, create it.
  • check if there is a global var. main. If not, create it.
  • add a method to the target SCDClass:

Final Action:

  • check if there is main method in the SCDClass. If not, create it.
  • compile implementation of main method, using the data from global var. main.
  • update the body of main with the latest code.
  • clean up any temporary objects that may have been created in this transformation.

Notes: Import data structures into the target SCD diagram - they will be subclassed into

  • TO DO for GG2SCD_GG_mdl:
    • Some sorting of associations is needed to ensure correct order of declaration in the code
    • How to deal with AToM3's getValue/setValue legacy?
    • Propose changes (AttrSpecify) in LHS of AToM3
    • Seperate code generation from concrete syntax (python)
    • Separate code generation routines for LHS and RHS
    • Update my PythonComposer to reflect new features of the SCD formalism
    • Comparing AToM3-generated traces to POKer-generated traces
    • Add reading semantic information of nodes
    • This code generation relies on assumption that data structure are already provided. How about code generating data structures themselves?
    • Identify areas where pattern matching of GG can be applied to my algorithm.
    • Implement pattern parameter
    • remove legacy relationship from PI metamodel, eventually rewrite the metamodel completely
    • Add initiation of new objects

[current]

Week 13

~ Meeting with Hans on Friday, 15:30. Talk about:

  • show Hans DEVS2ZProduct
  • brainstorm on GG2SCD
  • Talk about my thesis

+ Clean-up/finalise my models

+ Fix the SCD bugs. Note: Decorations in segments and links seem to be buggy, as AToM3 often does not remove them correctly.

+ Tack down loose ends:

  • Compile my deliverables.
  • Prepare file for transfer to NL, and publish them for MSDL

~ October 9: fly back to the Netherlands

On my return to the Netherlands

  • Send a thank you letter to MSDL people and invite them to Holland
  • Finish DEVS to ZProducts (before ESS'2003):
    • model Types2HTML_GG to generate web-interfaces for DEVS features.
    • fine-tune ZSCD2ZProduct_GG_mdl:
      • Take into account interfaces generated with Types2HTML_GG and located in external files.
      • See if anything is broken..
    • Update NCSE with new (DEVS) products and list them (products) in the Installed Components section of the site.
  • Make Power Point presentation for ESS'2003
  • Finish GG2SCD_GG_mdl:
    • make simple PI2POKer_GG_mdl that would generate a piDemos program from Piece in the PI formalism
    • make SCD2Python_GG_mdl to generate pure Python Code from SCD models.
    • verify that traces produced by POKer_GG and POKer.py are identical for equivalent programs.
  • Change PI_ER_mdl (related to GG2SCD_GG_mdl):
    • remove redundant relationships (e.g. Generator2Queue, InputQueue, OutputQueue, etc..).
    • more changes?
  • Thesis Style Guide for Hans.
  • Contact with Virtual Lab people; show my work.
  • Alexander Verbraeck. (what does he think about my ESS'2003 papaer?)
  • prolongation?
  • Icons for files in the Buttons formalism
  • Restore my custom manage_tabs for Zope
  • install structured text product in KBS's Zope.
  • Remove my old TUD web-page and post a list to my new homepage under Zope.
  • Install and try LyX.
  • clean up PythonComposer
  • Try to delegate "implementation of communication between AToM3 and ML" to a student as assignment.
  • Learn more about work of Sita Ramakrishnan
  • Refresh general hi-graphs, trees..