So I tried my hand on this, but with two reserves:
- I never wrote any real UML before, so I do not assure it is 100% formal and correct;
- I based the analysis on my engine, so I used some of my own terminology (ex: crossroad).
These are the main ideas I tried to put down:
- at the TDR level, I defined an abstract "pull" method for I/O, which is responsible for reading/writing to the register. The method would be
instantiated by an Access Interface, most typically becoming a JTAG CSU cycle. I believe this should be modelled by an UML "interface", but I
did not get that far yet.
- Instruments would have some abstract methods to implement (ex: "init" or "status"). I still have not decided if they should rather be independent nodes connected to one or more TDR (the "Raw instrument" of 1687) or a derivation of the TDR node with added functionalities
- for dynamic topologies, I use what I call "crossroad nodes", which contains a set of methods to manipulate, configure and query them. The idea is that any given arbitrary dynamic elements behaviour should be described through these primitives (a little bit like any algorithm can be executed through some basic assembler instructions), which can be freely overloaded by the instrument provider. I showed some examples of this in slides 2-3-4
- to allow for complex behaviour, I added some methods for "preconditioning" and "postconditioning", with an example of their usage in slide 5. The idea is it allow for configuration operations to be performed before and/or after the main data cycle.
- in an OO world, users could freely add methods and attributes to cater for their own needs, without breaking standard compliance. For instance in my implementation I use some tables and flags to help SIB and MIB methods, but which are not part of the basic primitive set.
So, any thoughts about this direction?