on SysML parametrics: intent and examples

[Russell Peak]

[I'm spawning this as a new topic thread]

 

Michael and Bran,

 

I would encourage you to take a look at this material if you have not seen it before:

 

Experiences Using SysML Parametrics to Represent Constrained Object-based Analysis Templates

- pde 2005 Presentation 1.2 (includes slides and webcast video archive)
- http://www.marc.gatech.edu/events/pde2005/presentations/ 

 

It may help your present discussions regarding the intent of parametrics (which can be used as a form of declarative knowledge representation).

 

I'll be posting more recent work within the next few days that has an updated version of these examples (which conforms more closely to the blocks-based parametric approach by Burkhart et al. included in the SST v0.98 submission).

 

Russell

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Michael Latta
Sent: Friday, December 16, 2005 3:27 PM
To: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] Re: [sysml-submission-team] [SysML-Evaluators] Re: Another view of "parsimony"

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

 

---

Russell S. Peak, PhD
Associate Director & Senior Researcher
 
Product & Systems Lifecycle Management (PSLM) Center
http://www.pslm.gatech.edu/
Defining next-generation systems-of-systems (SoS)
and product lifecycle management (PLM)
 
Georgia Institute of Technology
813 Ferst Drive, MARC 373
Atlanta, Georgia 30332-0560 USA
voice +1-404-894-7572
Russel...@gatech.edu

---

 

 

 

 

[Michael Latta]

Russell,

 

I have reviewed the indicated information and have the following additional comments:

 

1) Your material on the reasons to represent parametric relationships is quite good and is independent of the discussion about class vs. collaboration semantics for parametric representations on top of UML.

 

2) The remainder of your presentation focuses on the evaluation of constraints to perform analysis simulations.  While I understand the temptation to think of these as classes because you form "instances" within a simulator to evaluate the constraints, this is not a proper use of UML class semantics.  UML Class semantics are intended to represent instances that exist in the real world.  There never will be an "instance" of the constraint in the realization of a mechanical part such as the "Flap Link" you use in your example.  There will never be an instance of a mathematical equation between Force, Mass, and Acceleration.  This is a fundamental misuse of the UML class semantics and should not be used in SysML, not only because it is not the proper conceptualization of what a constraint is for System Engineering, but also because it is inappropriate to do so in a UML profile.

 

Michael

 

 

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Russell Peak
Sent: Friday, December 16, 2005 1:19 PM
To: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] on SysML parametrics: intent and examples

[Russell Peak]

Michael,

 

It seems there is fair amount of disagreement/confusion/misunderstanding on this topic.

 

Please take a look at constraint programming work like that by Al Borning (originator of ThingLab) et al. at U. Washington:

    http://www.cs.washington.edu/research/constraints/ (partially reproduced below for reference)

 

It is often convenient (and often necessary) to represent constraints using classes and instances. Constraint solving algorithms like their Cassowary and DeltaBlue take this for granted. 

 

Parametric CAD modelers do as well.  Exchange of such relations (as part of CAD models -- e.g., the relation between sleeve1.origin and sleeve2.origin in the flap link example) is a significant issue and need in industry today. For example, see the CHAPS (Construction History and Parametrics) work here: http://www.spans.org/library/

 

There are many other examples of how such constraints are indeed "instances that exist in the real world" (to the same extent that all conceptual, non-physical things like requirements, trade studies, allocations, and so on also exist in the real world and can be represented by UML classes).

 

I hope this helps clarify that instances of constraints are both useful and needful.

 

Russell

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Michael Latta

Sent: Friday, December 16, 2005 5:09 PM
To: SysML-Ev...@googlegroups.com
Subject: [SysML-Evaluators] Re: on SysML parametrics: intent and examples

 ...

 

2)  ...  UML Class semantics are intended to represent instances that exist in the real world.  There never will be an "instance" of the constraint in the realization of a mechanical part such as the "Flap Link" you use in your example.  There will never be an instance of a mathematical equation between Force, Mass, and Acceleration.  This is a fundamental misuse of the UML class semantics and should not be used in SysML, not only because it is not the proper conceptualization of what a constraint is for System Engineering, but also because it is inappropriate to do so in a UML profile. 

 

... 

 

=====

 

 

http://www.cs.washington.edu/research/constraints/

 

UW Constraint-Based Systems

Welcome to the home page for the Constraints research group at the Department of Computer Science and Engineering, University of Washington.

A constraint is a relation that should be satisfied -- for example, that a line remain horizontal, that a resistor in an electrical circuit simulation obey Ohm's Law, or that one column in a web page table be at least twice as wide as another. Constraints have been used in a variety of languages and systems, particularly in user interface toolkits, in planning and scheduling, and in simulation. UW constraints research has been in several areas, including the design and implementation of constraint solvers, applying constraints to user interface construction and to simulation, and the design and implementation of constraint programming languages.

The group is not currently active -- Alan Borning (the primary faculty member involved) has gotten distracted by the simulation of urban development -- but who knows; we might start up again sometime. There is certainly more to be done!

---

Papers

• Constraint Solvers
• Theory of Constraint Hierarchies
• Constraints and User Interfaces
• Constraints and the Web
• Constraint Imperative Programming
• Other Object-Oriented Programming
• Hierarchical Constraint Logic Programming
• Drafts of Papers

---

Solvers

We have designed a number of constraint satisfaction algorithms over the years, including DeltaBlue, SkyBlue, Indigo, Ultraviolet (is there a pattern here?), and Cassowary (I guess not). For researchers interested in experimenting with such algorithms, we recommend Cassowary; for certain applications, DeltaBlue may be useful as well.

The code for Cassowary and DeltaBlue is no longer supported, but we would still be pleased to hear about new applications of the solvers.

• Cassowary
• DeltaBlue

---

Videos

• ThingLab Presented at The Computing Form, Xerox PARC, June 1978. (Quicktime format - digitization courtesy of David Borning)

---

Other Information

Local:

• ftp site for UW source code

External:

• ThingLab: A Constraint-Oriented Simulation Laboratory (the original 1979 tech report, now in HTML and with the illustrations produced in the new Squeak port of ThingLab. Thanks to Reinier van Loon for doing this!)
• Constraint Programming Tutorial
• Constraints Archive page: general information on constraints and links to lots of interesting stuff

[Michael Latta]

I am afraid we may need to respectfully disagree on this.

 

Your examples keep coming back to evaluation of constraints for analysis or software purposes.  There is a fundamental difference between system behavior and model/analysis behavior.  While it may be useful to think of using classes and instances for analysis, that is fundamentally different from the kind of class/instance relationship represented by blocks/classes used in a system engineering model.  If we were modeling the analysis tool, then yes I might have a domain class for a constraint, which had instances used during the analysis.  If I was modeling a software system that evaluates constraints (such as some advanced UI systems or environments like ThingLab) I might want to model a domain class for constraint and use that in my application.  But, it is fundamentally wrong to mix classes of these types into the model for a system engineering project.  From the perspective of the System Engineering project the constraints are mathematical truths that are not "instanced" in the physical reality (atoms or bits) of the system.  An integrated analysis tool is certainly free to treat such constraints as instances of a class in the domain model of that analysis tool, but they are not classes from the perspective of the System Engineering project, and should not be classes from the perspective of SysML.

 

I have built several simulators for UML and system engineering languages, and it is very tempting to mix the domains from the tool with the domain of the language being served, but it is a very big mistake to do so.  We need to keep SysML focused on the domain of Systems Engineering, and leave the tool domain to another day and another model.

 

Michael

 

---

From: SysML-Ev...@googlegroups.com [mailto:SysML-Ev...@googlegroups.com] On Behalf Of Russell Peak
Sent: Friday, December 16, 2005 4:46 PM