Another view of "parsimony"

[Thomas Weigert]

While it may not be of primary interest to somebody who is only interested
in a system engineering notation, I believe we should nevertheless consider
how well each submission fits into the overall context of UML.

The reason for this is that system engineering is not done in isolation, but
at least for software systems the specifications will be handed off to teams
who will implement the software artifacts comprising the specified system.
These teams will most likely leverage UML to drive their development.

Questions that are of interest in this context are, for example:

* Does the profile introduce concepts that are inconsistent to existing UML
concepts (or are likely to be confused with existing, but different, UML
concepts)?

* Does the profile introduce a new concept where an existing UML concept
could have served equally well, or could have been easily extended to
address the perceived need?

* Does the profile introduce concepts in a manner that makes it difficult to
migrate the system specification into a UML specification of the software
subsystems during development?

I believe satisfactory answers to these types of questions are just as
important as to "does the profile support feature X" type questions, if we
want this profile to be used in real-life development.

Cheers, Th.

[Michael Latta]

Thomas,

I think you make good points. SysML needs to interoperate with UML well for
those cases where a component will be implemented in software. This also
means that things like allocation of one structural component to another
structure, needs to be reconciled with allocation of software artifacts to
hardware nodes. Deployment is like allocation, except that it occurs in the
real world instead of only in the model world, and occurs multiple times.
We also could look at reconciliation of software transformations into the SE
domain. Is this allocation in the SE sense or something else?

While I would like to have the interaction of SysML with software UML well
worked out before finalization of the specification, I suspect that is not
going to happen. We will have to settle for looking at how components are
represented in SysML and compare that to our use of UML in software
projects, as you suggest.

Do you have any specific concerns or examples of the things you question?

Michael

[Thomas Weigert]

Michael,

Looking at both specifications there are a number of differences I note with
respect to how well they integrate into the UML. Let me just give one
example:

Both specifications support the concept of parametric constraints, i.e.,
relationships between aspects of system components. The user level concept
is almost identical in both submissions (i.e., you can define, in a
graphical manner, relationships between elements by drawing a symbol
representing the constraint, and connecting this symbol with lines to the
elements which participate in the parametric relationship). However, there
are significant differences in how the submissions chose to implement these
concepts:

1. The SST submission represents a parametric constraint as a stereotyped
block (which in turn is a stereotyped class), and uses connectors between
model elements and parts (shown in port-like fashion) of the constraint
block to represent that the model elements participate in the parametric
relationship.

2. The SP submission represents a parametric constraint as a stereotyped
collaboration, and uses the UML mechanisms of collaboration use to represent
that certain model elements participate in the parametric relationship.

I find approach (2) superior by the criteria outlined below as it uses a UML
concept (collaboration) without changing its semantics. UML collaborations
are meant to describe relationships between various aspects of a specified
system without insisting that there is a physical reality to this
relationship, so it should come as no surprise that these are well-suited to
express parametric relationships.

In contrast, the SST submission takes a UML concept which inherently has a
physical instantiation semantics (that of Class) and changes its semantics
to not have an instantiation (since that would be meaningless for a
parametric constraint). Many other semantic aspects of UML classes are
stripped implicitly by the innocent looking stereotype (which, by the way,
is not supported by the UML profile mechanism). Then parametric constraints,
which are typically equations, are interpreted as "things" with "parts" (its
variables). Then UML connectors, which are concepts representing the
communication of something between elements, are reinterpreted as
relationships between the "parts" of these "equations". This is aggravated
by the notation making the variables in the equations look like UML ports.
From a UML point of view this representation is awkward and confusing, as
the UML concepts are reused in an inconsistent manner.

The notational and semantic confusion generated by the SST style
representation makes it also very difficult to show parametric constraints
as part of standard structural diagrams which would be a typical mode of
usage (e.g., structural elements in a system diagram are annotated with
parametric constraints), and not surprisingly, this usage mode is not
demonstrated. In contrast, this use is convenient in the SP submission and
also demonstrated in Figure 9-5.

Note again that for a user who does not care about the UML this may not be
very important, as such user will not be confused by the inconsistency in
concepts. However, I find it difficult to separate the SysML from the
underlying UML.

Cheers, Th.

[Michael Latta]

Thomas,

Thanks for the detail. I too find the collaboration notation a better
semantic fit since there are no instances for parametric constraints, but
you do a good job of taking that intuition and making the points concrete
and technically compelling for someone familiar with UML metamodeling.

Your arguments raise another similar one which while less of a difference
between the submissions has similar problems. Would it not be better to
represent requirements as a collaboration rather than as a stereotyped
block/class as well? The submissions have to go to awkward pains to deal
with the instance and other class related semantics, while a collaboration
has the decomposition, and model time semantics required for requirements.
What do you think about this?

[Branislav Selic]

Thomas,

With respect to:

> In contrast, the SST submission takes a UML concept which inherently has a
> physical instantiation semantics (that of Class) and changes its semantics
> to not have an instantiation (since that would be meaningless for a
> parametric constraint).

I too had concerns about this initially. However, Alan Moore pointed out to me that there is very good reason to represent so-called parametric "constraints" by classes/objects. Specifically, if you look at many examples of these constraints, you will notice that a substantial category of them incorporate state information in them. For example, a typical constraint formula is:

 y(n) := y(n-1) + a * [x(n) - x(n-1)]

where y(n-1) and x(n-1) are the values of y and x recorded in the preceding sampling cycle (sampling-based discretization is extremely common in such systems). This information needs to be stored somewhere and the best place to do that is in the attributes of the constraint object since you want to encapsulate this constraint-specific data.

Hence, it makes perfect sense to model them as classes/objects and their connections by connectors/links. So, this is quite in the spirit of UML.

It could be argued that the modeling of state-less constraints should then be done differently (e.g., using collaborations), but, in the spirit of parsimony that is clearly important here, it is much better if they were handled simply as degenerate cases of the state-based constraints. (A good compiler can certainly minimize or even eliminate any run-time overhead that such an object might imply.)

Cheers...Bran

[Michael Latta]

Bran,

 

I think you make Thomas's point exactly without meaning to.

 

The constraint example you provide is not something that "stores state" it is expressing a mathematical constraint on the functioning system.  The system being modeled is not storing the values of x[n-1] and y[n-1] in order to "compute" the constraint.  The constraint is a mathematical construct of the model and a design property of the resulting system.  If the system being modeled is expected to compute some value on an on-going basis that becomes a functional requirement of the system, not a parametric constraint.  The fact that you and others are getting the notion of a constraint confused with something the system should do, is exactly why a class based expression of these constraints is very dangerous.

 

Michael

 

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Branislav Selic
Sent: Thursday, December 15, 2005 9:00 AM
To: SysML-Ev...@googlegroups.com
Cc: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] Re: [sysml-submission-team] [SysML-Evaluators] Re: Another view of "parsimony"

[Thomas Weigert]

I agree 100% with Michael.

 

By UML definition, classes describe something that is instantiated in the system. Collaborations are used to define relationships or other aspects about the system that are not instantiated (are supervenient on the instantiated structures).

 

I think it is extremely dangerous to violate these definitions in a profile, ignoring that it is not even legal according to the UML profile mechanism.

 

If SysML is meant to be a UML profile, it should follow the rules of the profile. If it is a different language independent of the UML language family, we should stop pretending it is.

 

Cheers, Th.

[Branislav Selic]

Michale,

You wrote:

> If the system being modeled is
> expected to compute some value on an on-going basis that becomes a
> functional requirement of the system, not a parametric constraint.  
> The fact that you and others are getting the notion of a constraint
> confused with something the system should do, is exactly why a class
> based expression of these constraints is very dangerous.

My point was that the constraint is not really a constraint but--to use your terminology--the "system" ("component" is more appropriate). The purpose of these components is to perform computations. Technically, you can view such computations as constraints, but that is highly misleading.

Having other components compute and present these state values for reasons that they do not understand is a serious violation of encapsulation. In general, values such as y(n-1) really only exist so that the relevant computation can be performed, so they really belong with the computation. The supplier of the "y" value should not have any knowledge of how that value is used -- this is what component based design is all about.

Cheers...Bran

[Branislav Selic]

Thomas,

Please see my reply to Michael. I believe that the core of your argument about the incompatibility of UML and SysML is in the use of classes to capture constraints. As I pointed out to Michael, it turns out that the term "constraint" for these things is misleading (it may make sense in a very abstract conceptual model), and therefore I think that the incompatibility you are seeing does not really exist.

At the risk of dating myself, I have to admit that I used to work with analog computers in my early career. The type of expression that we are discussing here was typically implemented by an integrator circuit -- which is a very much a physical component in the system.

Cheers,
Bran

"Thomas Weigert" <thomas....@motorola.com> Sent by: SysML-Ev...@googlegroups.com 12/15/2005 08:28 PM Please respond to SysML-Evaluators

To <SysML-Ev...@googlegroups.com> cc

[Michael Latta]

Bran,

 

I am afraid that you are very much mistaken on the role parametric constraints serve in a System Engineering project.  It would be a gross violation of System Engineering discipline to have a constraint generate functionality into the system or component being specified.  All functional requirements must be modeled as the system component behavior not tucked away in a constraint.  The fact that you persist in representing the purpose of parametric constraints as doing run-time computation is very discouraging, and probably represents a very software biased viewpoint.  Also, this is not "methodology" but engineering.  The stated purpose of parametric constraints is to represent those constraints on the system/component such as physical forces that are known to hold or required to hold true within the design.  They are far more akin to OCL constraints in UML than they are to classes or blocks.  The constraints are however constraints on the system/component realization (atoms with serial numbers in David's terms) rather than the model itself.

 

Michael

 

 

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Branislav Selic

Sent: Friday, December 16, 2005 11:47 AM

To: SysML-Ev...@googlegroups.com
Cc: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] Re: [sysml-submission-team] [SysML-Evaluators] Re: Another view of "parsimony"

[Russell Peak]

Please reply to this parametrics discussion under this new topic
thread:

From: Russell Peak
Sent: Friday, December 16, 2005 4:19 PM
To: 'SysML-Ev...@googlegroups.com'
Subject: on SysML parametrics: intent and examples

http://groups.google.com/group/SysML-Evaluators/browse_frm/thread/39dd7547f4b89a48/718554d9c543bc2c#718554d9c543bc2c