From: Don Organ
Sent: Tuesday, November 19, 2002 12:54
PM
To: STIL. 4 (E-mail)
Subject: Regarding the 10/24/2002
FlowDiagram
Thanks to Jim and to
Ernie and others for the productive discussion today regarding the block
diagrams as posted on 10/24. I found this very helpful in understanding some of
the more subtle aspects of that model. I considered this discussion as intended
to help understanding of that model, rather than as "is that what we should
standardize on?".
Here are some of my
thoughts related to its applicability to standarization.
- Inheritance. I
consider inheritance (in the object oriented sense) a very powerful concept
and I very much like the approach where when a FlowNode calls a "test" and
that "test" can be either a test method or a subflow. However, STIL.4
will be specifying a syntax, and it is less clear to me how inheritance is
represented in syntax - or even if it is necessary or appropriate to do so.
Inheritance could be considered an implementation aspect, and therefore not be
explicitly identified in the language. For example, in looking at the STIL
data model (Annex B - informative) of 1450-1999, I see inheritance
(generalization - represented by a small upwards-pointing triangle with
lines coming out each vertex) being used in places where there isn't much/any
polymorphism (such as Pattern Statement), or where there is an invented
base-class (SignalRef) that doesn't otherwise appear in the language. Also,
what I thought was an example of inheritance (PatternBurst ISA Pattern) didn't
show up that way. So, I'm not saying inheritance is the wrong model, I'm just
questioning whether it is a concept that will be carried forward explicitly
into the syntax.
- It is interesting
to me how similar a Test Flow Node is to a Test - but that they are related to
each other in the inheritance model. As a designer I've learned that "similar
but different" often indicates that perhaps more refactoring of the model is
necessary/possible to make things that are similar actually be the same. I'm
not saying anything is wrong here, only that more thinking may be
warranted.
- Regarding tests
resolving to just a Pass/Fail. (this was still an open issue from earlier
discussions). I'm hoping we can find a way where the syntax is nice and simple
and obvious when a test returns pass/fail, but that scales easily
to other cases that can arise (such as an error return or returns only a
measurement, or returns one of N states). Certainly I agree that just
Pass/Fail probably covers >90% of the situations, and that the N-ports
capability at the enclosing FlowNode could cover those remaining cases, I'm
just not convinced yet that that is the best way to factor this
problem.
- In my mind, I group
the "Actions" (i.e. Pre-Action, Pass-Action, Fail-Action, N-Action) somewhat
differently. One group is what I'd call flow-control actions (such as the
by-pass capability, binning, selecting a port); these have direct execution
semantics. In another group, I think there is a need for user-controlled
actions (user-code), that would include saving values into a variable, but
also things like logging to a file or opening/closing a relay on the
loadboard. I don't think we'll be able to define what those are, but I think
we can/should accomodate those by placing some restrictions on where they can
occur. Perhaps "only in a test method" is a sufficient restriction, but that
seems overly limiting to me.
- I'm intrigued with
the by-pass capability. It seems like a good idea and easy to implement.
However, I note that it is not a capbility of other systems I'm familiar with
and that I don't remember any problems arising in those systems where
bypassing would have been the solution (I guess I'm questioning how essential
it is.) I do wonder if it might lead to some more subtle issues - such as how
to scope data produced by a test method such that it becomes invalid (or
defaulted?) if bypassed, or if there are any customer-user-code isses that
might arise.
- I've found that
applications engineers generally have wanted to be able to call more than one
test-method in sequence (from other system's equivalents of the same Test or
TestFlowNode). We've discussed this before and I haven't found much support
for this concept, but I look at what our users are doing and see that feature
is being used quite extensively. So I do wonder what impacts that would have
if added to the model.
-DVO-
---------------------------------------------------------------------------------
Don
Organ
Inovys Corporation
---------------------------------------------------------------------------------