[Smwg] AI2017-0512-54: Create draft Tech Note on State Machines
Shames, Peter M (312B)
Peter.M.Shames at jpl.nasa.gov
Wed Oct 3 15:26:52 UTC 2018
Sorry if it felt like I was attacking you. Besides, it was just a rubber dagger. ;-}
As a book editor I know first hand just how hard it is to produce any of these documents. And I know you put a lot of work into it. My intent was just to make sure that we use terminology consistently because to not do so causes confusion.
We'll work together to get it sorted out.
I find myself wondering if a source of the disconnect is the distinction between a procedural programming approach, where functions do the processing on exchanged data, and an object-oriented approach where the objects embed both data and functions performed on the data. Most of CCSDS at this point uses the former approach, and we tend to define functions (interfaces and behaviors), and services (which are defined as exposed functional interfaces), and data (which is exchanged at these interfaces).
Most CCSDS standards are defined specifically in terms that are language and implementation agnostic. And they tend to be defined using more of a procedure plus data paradigm in part because we have held that the nature and format of the data (information) are important and that if we get that right we can allow the interoperable systems to be implemented any way they want.
Is it possible that you were thinking of this in more O-O terms and that is what I stumbled upon?
Best regards, Peter
From: "Marcin.Gnat at dlr.de" <Marcin.Gnat at dlr.de>
Date: Tuesday, October 2, 2018 at 1:13 AM
To: Peter Shames <Peter.M.Shames at jpl.nasa.gov>
Cc: SMWG <smwg at mailman.ccsds.org>
Subject: RE: [Smwg] AI2017-0512-54: Create draft Tech Note on State Machines
And I was so happy finally getting this draft out, and you stab me a dagger in my back ;-).
Your concerns are I think very good. I can assure you, it was not my intention to be disjoint from CCSDS norms, and I’m ready to touch things up that they sound better. In general I think, the explanation would ben - I tried to walk some shortcuts to get some ideas on states/status written down. Maybe it got too messy, and maybe there are some terms not 100% correctly used – mea culpa ☺.
For you just to explain a bit more where I came from (and hoping maybe for some good tips how to improve):
- We have our file formats (SMURF, SPDF, etc…) which we consider being some representation of respective Information Entities
- When Information Entity is being ingested into the system, it will eventually be instantiated as an object (with functions and behaviors)
- We noticed, that while defining the formats, we can’t continue doing this completely not taking care about the state of the object/function which has been instantiated.
- So I got a task to make mind about what states and under what circumstances the objects can take, to see what are the dependencies between different functions and objects and where we need to look to get correct representation in form of some status parameter within respective Information Entity/File Format.
- I started off with Service Package lifecycle, and in result of mumbling around that, I got more and more into lifecycles/states of other formats/information Entities, operations and events which have effect on the objects/functional resources, which in turn maybe need to be represented somehow back within the file format.
- All this with premise to be valuable input for future automation services, currently just helping to figure out what status parameter we need to define for this or that file format, and what possible values it can take. No more and no less.
I hope it clarifies a bit…
From: Shames, Peter M (312B) [mailto:Peter.M.Shames at jpl.nasa.gov]
Sent: Montag, 1. Oktober 2018 17:15
To: Gnat, Marcin; smwg at mailman.ccsds.org
Subject: Re: [Smwg] AI2017-0512-54: Create draft Tech Note on State Machines
Dear Marcin & SMWG,
I have not (yet) studied this doc in detail, but I read the first few pages and I have a fundamental question to ask. Is it really the case that you define "Information Entities" to have states and behaviors, or is it the case that the (undefined) processes that manipulate and exchange these Information Entities have states and behaviors?
I tend to think of "Information" as being defined as data plus meta-data. And I think of an Information Entity as being an instance of an abstract information object. These entities carry information, and they may undergo transformation, extension, annotation, using well specified rules, but they do not, in an of themselves have behavior. Function have behaviors, and functions may specify that behavior using a state machine, or a sequence or activity diagram. I do think you can specify the expected evolution of an Information Entity using an activity diagram to show the flow from one configuration to another, but this is different than saying that it has behavior, rather that it is modified by the behavior of the functions that manipulate it.
If this sounds way off base please help me to understand the way you are using these basic terms because I think it is disjoint from the CCSDS norms.
From: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>> on behalf of "Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>" <Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>>
Date: Monday, October 1, 2018 at 5:33 AM
To: SMWG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: [Smwg] AI2017-0512-54: Create draft Tech Note on State Machines
And here is another debt which I had in terms of an Action Item. Please see attached draft Tech Note on State Machines. Also some small corresponding presentation (content is more or less same).
Uploaded to CWE as well:
MagicDraw UML File:
I saw Erik had planned some time during Fall Meetings for the State Machine topic, so maybe it would be not bad if you could drop an eye on this stuff (one more doc to be reviewed – add to the list of “Berlin Pointers” ;-). It’s not long though… so maybe you can make it…
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SMWG