Revision 420 open for discussion

I have made a few changes to Oatc_Dev_2_0\OpenMI.Standard, mainly concerning
the input/output exchange items and the data operations, including their
update calls and values-getters. I briefly discussed a few things with Gena,
but no real details yet. Next week we will work on it together.

The main changes are:
- Item, InputItem and OutputItem are gone, and are replaced by an
ExchangeItem, with a role.
- The DataOperation extends the ExchangeItem (role is then output).
  (please have a look at the DataOperation's comment to see why
   in my view this makes sense)

To form an opinion about it, please have a detailed look at
    NUnitUseCases\CreateCompositionTest.cs
There are four methods:
1. Creating a 'chain' of data-operations.
2. The calibration example that we discussed at the last meeting.
3. The 'connecting 2 components' example that we already had in earlier
    examples.
4. A look inside a LC's Update function, i.e. how it could be implemented
   (comparible to the 'smart wrapper').
Both 2. and 3. use 1. to establish the 'link'.

I didn't find time yet to create and/or update sequence diagrams, class
diagrams, etc., but hopefully the ideas become clear from the example code.

If you think this might be a step in the right direction (i.e. at least not
in the wrong direction), my next action will be to investigate what to do
make the SDK and the GUI up and running again.

Please let me know what you think.

Best regards,
Stef.

 

  • No labels

2 Comments

  1. Peter Gijsbers



    Hi Stef,

    I also looked in more details on changes (only IExchageItem (smile) ), here are several additional suggestions:

    1) Role - should be moved into a separate file ExchangeItemRole.cs (see class library design guidelines)

    2) Role.Input, Role.RequiredInput - I'm more in favor to have only Input and Output. Mixing them together makes things more complicated.

    public enum ExchangeItemRole { Input, Output } \\

    3) bool DescribeSameAs(IExchangeItem)  - maybe better bool CanConsumeValueFrom(IExchangeItem)

    4) Consumers, Provider probably should be ValueConsumers, ValueProvider - more explicitly means what they consume or provide.

    5) It seems to be useful to add 

    *{_}IComponent{_}* *{_}Component{_}* *{ get; set; }* property to *IExchangeItem*

    - it will make interface much more intuitive (it is associated with a component in most cases anyway):

    IExchangeItem ei1 = c1.Output[0];
    IExchangeItem ei2 = c1.Input[0];

    ei2.Provider = ei1;

    // show id of the component that provides values for ei2

    MessageBox.Show(ei2.Provider.Component.ID); // will show c1.ID

    6) EarliestInputTime - alternative to it may be also to use TimeHorizon provided by the target component:

    IExchangeItem src = c1.Output[0];
    IExchangeItem dst = c2.Input[0];

    dst.Provider = src;

    c1 can can always check *how far target components may go back in time
    * using src.Consumer[0].Component.TimeHorizon;
    the same as c2 can always check for the time window of provided component using dst.Provider.Component.TimeHorizon;

    7) Update(), UpdateTime(time) - why not to leave it only in Component? Inside ExchangeItem we can use some king of filtering approach instead. E.g.:

    interface IComponent
{
 Update(...) - updates component state by running simulation, extracting data from a database, etc.
}

interface IExchangeItem
{
  public Value { get; set; } \\ \\

  public Type ValueType { get; }

  public IValueFilter ValueFilter { get; set; } ; - allows to inject custom value filters (always limit values by duration, space, etc.), null by default.
}

    Example of filter may be functionality similar to FEWS relative view period. Thas IExchangeItem.ValueFilter might be initialized during design time and then only IComponent.Update(...) will need to be called during run time to get new values. (will discuss it and make examples next week)

    Best regards,
    Gena

  2. Peter Gijsbers

    Hi Stef,

    It looks pretty good, especially the fact that data retrieval is not time
    dependent anymore. However, it took quite a lot to get the picture clear in my
    mind. The most difficult bit for me (to explain to others) remains the
    appearance of the Update-method in two classes. I therefore have difficulty to
    grasp how a two-way interaction would work. An example for that one would but
    nice. Similarly, I would appreciate a example where one has full control on the
    starting conditions (set start time, set state from disk).

    NB the enumeration for Role is used nowhere. Do we need it/can we skip it ?

    best regards,
    Peter

    NB. I like to get something better for EarliestInputTime. I do think the suggestion by Genna is a nice one but it needs some exercise/example to see if it works

Disclaimer