Issue 16594: Constraint Blocks cannot have parameters (sysml-rtf) Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Clarification Severity: Minor Summary: It looks the Parametrics chapter is inconsistent about properties of constraint blocks. In one place it says they must be constraint properties, and in others it says they do not need to be. I assume constraint blocks can have properties that are not constraint properties, and these properties are informally called "parameters", is that right? If not, how are constraint parameters represented? Specifically (in the beta2, inherited from 1.2): - Section 10.3.2.2 (ConstraintProperty), Constraints subsection says "[2]The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock." - Section 10.3.1.1 (Block Definition Diagram), Parameters Compartment subsection, says "Properties of a constraint block should be shown either in the constraints compartment, for nested constraint properties, or within the parameters compartment", which presumably means parameters are properties that are not constraint properties. - Section 10.3.2.1 (ConstraintBlock): Constraints Compartment subsection, says "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks" Constraints, "[1] A constraint block may not own any structural or behavioral elements beyond the properties that define its constraint parameters, constraint properties that hold internal usages of constraint blocks, ..." Resolution: Revised Text: Actions taken: October 13, 2011: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 13 Oct 2011 11:58:06 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Conrad Bock Employer: NIST mailFrom: conrad.bock@nist.gov Terms_Agreement: I agree Specification: SysML 1.3 beta 2 Section: Parametrics FormalNumber: ptc/11-08-09 Version: Doc_Year: 2011 Doc_Month: September Doc_Day: 01 Page: Title: Constraint Blocks cannot have parameters Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Description: It looks the Parametrics chapter is inconsistent about properties of constraint blocks. In one place it says they must be constraint properties, and in others it says they do not need to be. I assume constraint blocks can have properties that are not constraint properties, and these properties are informally called "parameters", is that right? If not, how are constraint parameters represented? Specifically (in the beta2, inherited from 1.2): - Section 10.3.2.2 (ConstraintProperty), Constraints subsection says "[2]The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock." - Section 10.3.1.1 (Block Definition Diagram), Parameters Compartment subsection, says "Properties of a constraint block should be shown either in the constraints compartment, for nested constraint properties, or within the parameters compartment", which presumably means parameters are properties that are not constraint properties. - Section 10.3.2.1 (ConstraintBlock): Constraints Compartment subsection, says "All properties of a constraint block are constraint parameters, with the exception of constraint properties that hold internally nested usages of other constraint blocks" Constraints, "[1] A constraint block may not own any structural or behavioral elements beyond the properties that define its constraint parameters, constraint properties that hold internal usages of constraint blocks, ..." DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=UmaAuyXur/g8RehbtXbOGj3khklKPOj3dSsum6ksFhQ=; b=bohjoTtGcyu11AfECyvsWUESV9N4GeS3mTiId4oQuB339iO4NLuhyRqFMwtVFptc2J Zsr3MYXgffp3e7Ei/mr3arRZhQWqUJdcHksHGLrF/5kejPVPck4N8zmGkP4sy2xqUQxT ehBPCF4ivAKH7p9IXANykOxaxJrRE+993D5Dc= From: "Sanford Friedenthal" To: "'Bock, Conrad'" , Cc: "'Matei, Ion'" Subject: RE: Parametrics inconsistency, properties of constraint blocks Date: Thu, 13 Oct 2011 11:40:25 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyJvDH76XMxHF64TkCqzzLdfPRDCQAAbK1g Conrad A constraint property always typed by a constraint block. A parameter is a property of a constraint, but we do not refer to the parameter as a constraint property but rather as a constraint parameter. I see how this is confusing, and I would think we do need to clarify this terminology. Sandy -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, October 13, 2011 11:24 AM To: sysml-rtf@omg.org Cc: Matei, Ion Subject: Parametrics inconsistency, properties of constraint blocks Parameterizers, It looks the Parametrics chapter is inconsistent about properties of constraint blocks. In one place it says they must be constraint properties, and in another it says they do not need to be. Specifically (in the beta2, inherited from 1.2): - Section 10.3.1.1 (Block Definition Diagram), Parameters Compartment subsection, it says "Properties of a constraint block should be shown either in the constraints compartment, for nested constraint properties, or within the parameters compartment", which presumably means parameters are properties that are not constraint properties. - Section 10.3.2.2 (ConstraintProperty), Constraints subsection says "[2]The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock." I assume constraint blocks can have properties that are not constraint properties, and these properties are informally called "parameters", is that right? If so, will file an issue. If not, how are constraint parameters represented? Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" CC: "Matei, Ion" Date: Thu, 13 Oct 2011 11:45:41 -0400 Subject: RE: Parametrics inconsistency, properties of constraint blocks Thread-Topic: Parametrics inconsistency, properties of constraint blocks Thread-Index: AcyJvDH76XMxHF64TkCqzzLdfPRDCQAAbK1gAAAwJ4A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Sandy, > A parameter is a property of a constraint, but we do not refer to the > parameter as a constraint property but rather as a constraint > parameter. I see how this is confusing, and I would think we do need > to clarify this terminology. The terminology is fine (or at least that's not the issue I'm raising). The problem is ConstraintProperty has a constraint preventing them from having parameters: [2] The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock. All properties of ConstraintBlocks must be ConstraintProperties. I'm assuming that's not intended. Conrad DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=OOfjSa3RU/Fe2cu9fATAyqHK8cRBd/DdDCmnX5uV2Ek=; b=gZSRqOErrDxXM5d3ruVe1vXA/eUVSojwOaRsuBGdouN4cic4Qd7TAHHMU9XcAyHpgs t2WH3c6dPRkvWQ17j2tYt19pWIBfyXIYiL17dHU3gRJ9MFSZYe/q9ftuQMNKkl2d34z8 9U2UtTaPhG8LMWo9O1BlptBOtkf229F5EgeOw= From: "Sanford Friedenthal" To: "'Bock, Conrad'" , Cc: "'Matei, Ion'" Subject: RE: Parametrics inconsistency, properties of constraint blocks Date: Thu, 13 Oct 2011 11:48:29 -0400 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyJvDH76XMxHF64TkCqzzLdfPRDCQAAbK1gAAAwJ4AAADkvIA== You are correct. -----Original Message----- From: Bock, Conrad [mailto:conrad.bock@nist.gov] Sent: Thursday, October 13, 2011 11:46 AM To: sysml-rtf@omg.org Cc: Matei, Ion Subject: RE: Parametrics inconsistency, properties of constraint blocks Sandy, > A parameter is a property of a constraint, but we do not refer to the > parameter as a constraint property but rather as a constraint > parameter. I see how this is confusing, and I would think we do need > to clarify this terminology. The terminology is fine (or at least that's not the issue I'm raising). The problem is ConstraintProperty has a constraint preventing them from having parameters: [2] The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock. All properties of ConstraintBlocks must be ConstraintProperties. I'm assuming that's not intended. Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" CC: "Matei, Ion" Date: Thu, 13 Oct 2011 11:49:56 -0400 Subject: RE: Parametrics inconsistency, properties of constraint blocks, correction Thread-Topic: Parametrics inconsistency, properties of constraint blocks, correction Thread-Index: AcyJvDH76XMxHF64TkCqzzLdfPRDCQAAbK1gAAAwJ4A= Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Correction. Sandy, > A parameter is a property of a constraint, but we do not refer to the > parameter as a constraint property but rather as a constraint > parameter. I see how this is confusing, and I would think we do need > to clarify this terminology. The terminology is fine (or at least that's not the issue I'm raising). The problem is ConstraintProperty has a constraint preventing Constraint Blocks from having parameters: [2] The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock. All properties of ConstraintBlocks must be ConstraintProperties. I'm assuming that's not intended. Conrad From: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" CC: "sysml-rtf@omg.org" , "Matei, Ion" Date: Thu, 13 Oct 2011 09:01:23 -0700 Subject: Re: Parametrics inconsistency, properties of constraint blocks Thread-Topic: Parametrics inconsistency, properties of constraint blocks Thread-Index: AcyJwVs2LEnXCGTSSvymGx9AfDGuYw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Conrad, Are you sure you are distinguishing between owning vs. typing a property? On Oct 13, 2011, at 8:45 AM, Bock, Conrad wrote: Sandy, The problem is ConstraintProperty has a constraint preventing them from having parameters: [2] The ConstraintProperty stereotype must be applied to any property of a SysML Block that is typed by a ConstraintBlock. [2] is about owned properties that are typed by a ConstraintBlock. All properties of ConstraintBlocks must be ConstraintProperties. How do you logically conclude that the type of the property is irrelevant? I'm assuming that's not intended. This is not intended, a ConstraintBlock could have a ValueProperty for example. - Nicolas. Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" CC: "Matei, Ion" Date: Thu, 13 Oct 2011 12:14:53 -0400 Subject: RE: Parametrics inconsistency, properties of constraint blocks Thread-Topic: Parametrics inconsistency, properties of constraint blocks Thread-Index: AcyJwVs2LEnXCGTSSvymGx9AfDGuYwAAZLEA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Nicolas, > [2] The ConstraintProperty stereotype must be applied > to any property > of a SysML Block that is typed by a ConstraintBlock. > [2] is about owned properties that are typed by a ConstraintBlock. OK, thx, I was reading that as "stereotyped by a ConstraintBlock". Will make the issue easy to resolve. :) Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" CC: "Matei, Ion" Date: Thu, 13 Oct 2011 13:38:50 -0400 Subject: RE: Parametrics inconsistency, properties of constraint blocks Thread-Topic: Parametrics inconsistency, properties of constraint blocks Thread-Index: AcyJwVs2LEnXCGTSSvymGx9AfDGuYwADUPIw Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US P.S. If constraint properties must be typed by constraint blocks and properties typed by constraint blocks must be constraint properties, I'm not sure what the purpose of the ConstraintProperty stereotype is. Every property typed by a ConstraintBlock could be called constraint property, no stereotype is needed. Conrad From: "Rouquette, Nicolas F (313K)" To: "Bock, Conrad" CC: "sysml-rtf@omg.org" , "Matei, Ion" Date: Thu, 13 Oct 2011 11:13:26 -0700 Subject: Re: Parametrics inconsistency, properties of constraint blocks Thread-Topic: Parametrics inconsistency, properties of constraint blocks Thread-Index: AcyJ083HHMkkxHetRn6KPKO96GNfDw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p9DIChvc003353 In SysML, properties of a block can be classified in five disjoint categories: parts, references, values, constraints, uml. The classification depends on meta-properties: multiplicity (part vs. reference) and type (part vs. value vs. constraint). A value property is typed by a <> DataType; part, reference & constraint properties are typed by a <> Class. Distinguishing between a part vs. constraint property is a bit more expensive since one has to check whether any applied stereotype is a kind of <> instead of just <> Therefore, there is a utility for tools and for reasoning engines to have <> -- it represents a the (cached) result of a logical entailment about sysml property classification. - Nicolas. On Oct 13, 2011, at 10:38 AM, Bock, Conrad wrote: > P.S. If constraint properties must be typed by constraint blocks and > properties typed by constraint blocks must be constraint properties, I'm > not sure what the purpose of the ConstraintProperty stereotype is. > Every property typed by a ConstraintBlock could be called constraint > property, no stereotype is needed. > > Conrad From: "Bock, Conrad" To: "sysml-rtf@omg.org" Date: Thu, 13 Oct 2011 14:25:01 -0400 Subject: RE: Parametrics, constraint property stereotype Thread-Topic: Parametrics, constraint property stereotype Thread-Index: AcyJ083HHMkkxHetRn6KPKO96GNfDwAARmAg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Nicolas, > Therefore, there is a utility for tools and for reasoning engines to > have <> -- it represents a the (cached) result of > a logical entailment about sysml property classification. Tools can do their own optimizations without it, as they would need to for the other items below. It more work for the tool or the user to apply the redundant stereotype. Conrad > The classification depends on meta-properties: multiplicity > (part vs. reference) and type (part vs. value vs. constraint). > A value property is typed by a <> DataType; part, > reference & constraint properties are typed by a <> Class. > Distinguishing between a part vs. constraint property is a > bit more expensive since one has to check whether any > applied stereotype is a kind of <> instead > of just <>