Issue 16016: SysML Issue on Refine limitations (sysml-rtf) Source: Lockheed Martin (Mr. Michael Jesse Chonoles, michael_chonoles2(at)omg.org) Nature: Uncategorized Issue Severity: Summary: The text description of how the refine relationship can be used disagrees with formal restrictions. On page 126, 2nd paragraph, the text says. “The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.” This allows a refine relationship to be [Requirement] ß1..*[Model element] Or [Requirement] à [Model element] However, Figure 16.1 only has /refinedBy:Named Element[*] as property for a Requirement Thus it is not possible to have a requirement refine a model element. This is confirmed by Figure 16.2, which in showing the tags for a NamedElement Has /refines Requirement [*] This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around). So problem 1. The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence: The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element. Problem 2 The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word “diagram” from the text Final wording The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement. Additional comment. It’s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement. Resolution: Revised Text: Actions taken: February 9, 2011: received issue Discussion: End of Annotations:===== te: Wed, 09 Feb 2011 12:48:43 -0500 From: "Chonoles, Michael J" Subject: SysML Issue on Refine limitations To: Juergen Boldt , "issues@omg.org" Cc: "sysml-rtf@omg.org" Thread-Topic: SysML Issue on Refine limitations Thread-Index: AcvBYVSimzDMXM4lTkWQO1ISPe932AHGBzYw Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-09_06:2011-02-09,2011-02-09,1970-01-01 signatures=0 The text description of how the refine relationship can be used disagrees with formal restrictions. On page 126, 2nd paragraph, the text says. .The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.. This allows a refine relationship to be [Requirement] ß..*[Model element] Or [Requirement] à [Model element] However, Figure 16.1 only has /refinedBy:Named Element[*] as property for a Requirement Thus it is not possible to have a requirement refine a model element. This is confirmed by Figure 16.2, which in showing the tags for a NamedElement Has /refines Requirement [*] This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around). So problem 1. The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence: The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element. Problem 2 The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word .diagram. from the text Final wording The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement. Additional comment. It.s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement. Michael Chonoles LMCO DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=0xijpGfAMs/rROIkO58BWiyM4EDUejDItd2oTF2E9CE=; b=BAnI+tZhbBXjeUgSvy1ORWEhB/UpK6DD4ZxxctR/mPxrLFYN7RVvIL8TtSUdJNpkxS mX1yWwtZzFWGtfAmQTSJZwZtj+yAde/O5386MVzizeeoT4WhJgtCAOx3BS1dEtQ9/6OM ltaiHNuNDxdyhPek0g9OYNQJJeI16grOKqlpw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=lr4S8wcS/omjkDjFiHatT2+UCL4i4Z7fNtquWZZgZrsZYx5tQ1NP9Ig1GM3m/sgS60 kjz2tBJrr2cthHM9YFK+lyk6MTlpjG+BBmJaa5L4c1b/xUc+t5UDvcvXqZ+9+P/NgCjQ aLP2kt9/NR4F/7GKGdQmWwkyb9jKScvDR7Jh4= From: "Sanford Friedenthal" To: "'Chonoles, Michael J'" , "'Juergen Boldt'" , Cc: Subject: RE: SysML Issue on Refine limitations Date: Wed, 9 Feb 2011 21:24:54 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvBYVSimzDMXM4lTkWQO1ISPe932AHGBzYwAAyeWqA= Michael We may want to fix this so that a requirement can refine a model element. Thanks for the catch. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Wednesday, February 09, 2011 12:49 PM To: Juergen Boldt; issues@omg.org Cc: sysml-rtf@omg.org Subject: SysML Issue on Refine limitations The text description of how the refine relationship can be used disagrees with formal restrictions. On page 126, 2nd paragraph, the text says. .The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.. This allows a refine relationship to be [Requirement] ß..*[Model element] Or [Requirement] à [Model element] However, Figure 16.1 only has /refinedBy:Named Element[*] as property for a Requirement Thus it is not possible to have a requirement refine a model element. This is confirmed by Figure 16.2, which in showing the tags for a NamedElement Has /refines Requirement [*] This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around). So problem 1. The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence: The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element. Problem 2 The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word .diagram. from the text Final wording The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement. Additional comment. It.s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement. Michael Chonoles LMCO From: "BERNARD, Yves" To: Sanford Friedenthal , "'Chonoles, Michael J'" , "'Juergen Boldt'" , "issues@omg.org" CC: "sysml-rtf@omg.org" Date: Thu, 10 Feb 2011 08:04:24 +0100 Subject: RE: SysML Issue on Refine limitations Thread-Topic: SysML Issue on Refine limitations Thread-Index: AcvBYVSimzDMXM4lTkWQO1ISPe932AHGBzYwAAyeWqAAER0v0A== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Michael, Sandy, I confirm that, even if it.s not my preferred way of working, we have some case where such a capability could be useful. Currently we use a <> relationship for that purpose. Yves From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: jeudi 10 féier 2011 03:25 To: 'Chonoles, Michael J'; 'Juergen Boldt'; issues@omg.org Cc: sysml-rtf@omg.org Subject: RE: SysML Issue on Refine limitations Michael We may want to fix this so that a requirement can refine a model element. Thanks for the catch. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Wednesday, February 09, 2011 12:49 PM To: Juergen Boldt; issues@omg.org Cc: sysml-rtf@omg.org Subject: SysML Issue on Refine limitations The text description of how the refine relationship can be used disagrees with formal restrictions. On page 126, 2nd paragraph, the text says. .The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.. This allows a refine relationship to be [Requirement] ß..*[Model element] Or [Requirement] à [Model element] However, Figure 16.1 only has /refinedBy:Named Element[*] as property for a Requirement Thus it is not possible to have a requirement refine a model element. This is confirmed by Figure 16.2, which in showing the tags for a NamedElement Has /refines Requirement [*] This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around). So problem 1. The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence: The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element. Problem 2 The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word .diagram. from the text Final wording The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement. Additional comment. It.s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement. Michael Chonoles LMCO This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Date: Fri, 11 Feb 2011 10:54:02 -0500 From: "Chonoles, Michael J" Subject: RE: 16016 -- QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd CommentRe: Ex: RE: SysML Issue on Refine limitations To: "Rouquette, Nicolas F (313K)" , Sanford Friedenthal Cc: Juergen Boldt , "issues@omg.org" , "sysml-rtf@omg.org" , "BERNARD, Yves" Thread-Topic: 16016 -- QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd CommentRe: Ex: RE: SysML Issue on Refine limitations Thread-Index: AcvJc88X0o2Y0MvoQC6e5Uq7cXNMXAAjwEQw Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2011-02-11_06:2011-02-11,2011-02-11,1970-01-01 signatures=0 Nicolas, I not sure what you.re saying, however, there are still issue(s) 1) The SysML .refine requirement relationship. cannot be used both ways because we have not added the derived properties to requirements and namedelement (as we did with the other requirement relationships) to support this. The two refine relationships are not the same relationship. Therefore the SysML spec text must be corrected. 2) We can.t have a diagram refine anything. The SysML spec text must be corrected. Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, February 10, 2011 5:43 PM To: Chonoles, Michael J; Sanford Friedenthal Cc: Juergen Boldt; issues@omg.org; sysml-rtf@omg.org; BERNARD, Yves Subject: 16016 -- QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd CommentRe: Ex: RE: SysML Issue on Refine limitations Michael, Sandy: I propose to resolve this issue as: no change. We should be aware that there is a UML «refine» relationship that can be used between any model element (and it may be bi-directional) This is incorrect. Per UML2.4, Figure C.1, UML::Refine is a stereotype extending UML::Abstraction, which is a specialization of UML::Dependency Per UML2.4, clause 7.3.12, the client/supplier of a UML::Dependency are UML::NamedElement. Therefore, a UML::Refine relationship be used between any model elements that are of kind UML::NamedElement. The UML::Refine relationship is unidirectional because UML::Dependency is a kind of UML::DirectedRelationship. All of SysML's requirement-related relationships in clause 16.3.2 of SysML1.2 are specializations of UML4SysML::Trace, which corresponds to UML::Trace, which is a stereotype extending UML::Abstraction, just like UML::Refine does above. Therefore, all of SysML's requirement-related relationships are perfectly compatible with UML::Refine stereotype relationship from UML2.4's StandardProfileL2. Please be careful with the term "model element" in the SysML specification. It is used in different contexts to mean different things. There is a "SysML::ModelElements" package that adds to the confusion in figure 4.3. In clause 16, the term "model element" is used loosely without precisely describing what kind of SysML-stereotyped UML4SysML it refers to. Note that the set of model elements that are a kind of UML4SysML::Element, are not abstract, are not a kind of UML4SysML::Relationship and *not* a kind of UML4SysML::NamedElement is precisely: QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd Comment The list above are the concrete metaclasses that we would be able to include in the requirement derived properties if we relaxed their type from UML4SysML::NamedElement to UML4SysML::Element Is this useful? No. Why? There is nothing in UML2.4 we can use to establish any kind of relationship between a SysML::Requirement and any of the above metaclasses unless it is by ownership (e.g., Comment or a property typed by one of these metaclasses). - Nicolas. On Feb 10, 2011, at 12:01 PM, Chonoles, Michael J wrote: Re:issue 16016 Yes, that.s also a possible fix. I picked the simpler one for the first proposal. Yves has also suggested we fix it to go the other way. We should be aware that there is a UML «refine» relationship that can be used between any model element (and it may be bi-directional) There doesn.t seem to be any relationship between the SysML «refine» and the UML «refine», and only the SysML refine requirement relationship can use the callout notation. It.s unclear whether the UML «refine» would be allowable in a SysML model. From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Wednesday, February 09, 2011 9:25 PM To: Chonoles, Michael J; 'Juergen Boldt'; issues@omg.org Cc: sysml-rtf@omg.org Subject: Ex: RE: SysML Issue on Refine limitations Michael We may want to fix this so that a requirement can refine a model element. Thanks for the catch. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Wednesday, February 09, 2011 12:49 PM To: Juergen Boldt; issues@omg.org Cc: sysml-rtf@omg.org Subject: SysML Issue on Refine limitations The text description of how the refine relationship can be used disagrees with formal restrictions. On page 126, 2nd paragraph, the text says. .The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.. This allows a refine relationship to be [Requirement] ß..*[Model element] Or [Requirement] à [Model element] However, Figure 16.1 only has /refinedBy:Named Element[*] as property for a Requirement Thus it is not possible to have a requirement refine a model element. This is confirmed by Figure 16.2, which in showing the tags for a NamedElement Has /refines Requirement [*] This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around). So problem 1. The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence: The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element. Problem 2 The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word .diagram. from the text Final wording The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement. Additional comment. It.s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement. Michael Chonoles LMCO From: "Rouquette, Nicolas F (313K)" To: "Chonoles, Michael J" , Sanford Friedenthal CC: Juergen Boldt , "issues@omg.org" , "sysml-rtf@omg.org" , "BERNARD, Yves" Date: Thu, 10 Feb 2011 14:42:33 -0800 Subject: 16016 -- QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd CommentRe: Ex: RE: SysML Issue on Refine limitations Thread-Topic: 16016 -- QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd CommentRe: Ex: RE: SysML Issue on Refine limitations Thread-Index: AcvJc88X0o2Y0MvoQC6e5Uq7cXNMXA== 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 Michael, Sandy: I propose to resolve this issue as: no change. We should be aware that there is a UML «refine» relationship that can be used between any model element (and it may be bi-directional) This is incorrect. Per UML2.4, Figure C.1, UML::Refine is a stereotype extending UML::Abstraction, which is a specialization of UML::Dependency Per UML2.4, clause 7.3.12, the client/supplier of a UML::Dependency are UML::NamedElement. Therefore, a UML::Refine relationship be used between any model elements that are of kind UML::NamedElement. The UML::Refine relationship is unidirectional because UML::Dependency is a kind of UML::DirectedRelationship. All of SysML's requirement-related relationships in clause 16.3.2 of SysML1.2 are specializations of UML4SysML::Trace, which corresponds to UML::Trace, which is a stereotype extending UML::Abstraction, just like UML::Refine does above. Therefore, all of SysML's requirement-related relationships are perfectly compatible with UML::Refine stereotype relationship from UML2.4's StandardProfileL2. Please be careful with the term "model element" in the SysML specification. It is used in different contexts to mean different things. There is a "SysML::ModelElements" package that adds to the confusion in figure 4.3. In clause 16, the term "model element" is used loosely without precisely describing what kind of SysML-stereotyped UML4SysML it refers to. Note that the set of model elements that are a kind of UML4SysML::Element, are not abstract, are not a kind of UML4SysML::Relationship and *not* a kind of UML4SysML::NamedElement is precisely: QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd Comment The list above are the concrete metaclasses that we would be able to include in the requirement derived properties if we relaxed their type from UML4SysML::NamedElement to UML4SysML::Element Is this useful? No. Why? There is nothing in UML2.4 we can use to establish any kind of relationship between a SysML::Requirement and any of the above metaclasses unless it is by ownership (e.g., Comment or a property typed by one of these metaclasses). - Nicolas. On Feb 10, 2011, at 12:01 PM, Chonoles, Michael J wrote: Re:issue 16016 Yes, that.s also a possible fix. I picked the simpler one for the first proposal. Yves has also suggested we fix it to go the other way. We should be aware that there is a UML «refine» relationship that can be used between any model element (and it may be bi-directional) There doesn.t seem to be any relationship between the SysML «refine» and the UML «refine», and only the SysML refine requirement relationship can use the callout notation. It.s unclear whether the UML «refine» would be allowable in a SysML model. From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Wednesday, February 09, 2011 9:25 PM To: Chonoles, Michael J; 'Juergen Boldt'; issues@omg.org Cc: sysml-rtf@omg.org Subject: Ex: RE: SysML Issue on Refine limitations Michael We may want to fix this so that a requirement can refine a model element. Thanks for the catch. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Wednesday, February 09, 2011 12:49 PM To: Juergen Boldt; issues@omg.org Cc: sysml-rtf@omg.org Subject: SysML Issue on Refine limitations The text description of how the refine relationship can be used disagrees with formal restrictions. On page 126, 2nd paragraph, the text says. .The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.. This allows a refine relationship to be [Requirement] ß..*[Model element] Or [Requirement] à [Model element] However, Figure 16.1 only has /refinedBy:Named Element[*] as property for a Requirement Thus it is not possible to have a requirement refine a model element. This is confirmed by Figure 16.2, which in showing the tags for a NamedElement Has /refines Requirement [*] This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around). So problem 1. The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence: The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element. Problem 2 The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word .diagram. from the text Final wording The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement. Additional comment. It.s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement. Michael Chonoles LMCO DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=E7d1+3bMs7Mr1zj1qLdytakYimBCqNgaxQxIOWP94UY=; b=mTGr9AQGBpYhfM1tcKzliJwn52BoSinNbC3dtxFkLduhrPO6VnJ0X+4CzXWtF9p/KL Rl5Sc6xlc6KIUhgS1bX0HoIqYD9T6gu05Hh7iq5kSltSEg6m/QFZhxGg32+Q533V7DgU RZHhCrgMAnxy56LAQmGWklD9vZnutGccfg44M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=on3v2xm6NWgGLUfMkweRr5KRykXLV2X3tpP7zsugpya/rNs7XkBjAjjgT991AWcY6Y 0ArhRUCE2NpVG7hqJ0oHgzvwthZoBGDqOTac84RegxxYI6AnHHvm2kHH9mL3Kvk8h2Ms r7YfD4aJiHkjznGL3b5iYIHIUk2pwVYtfHDPc= From: "Sanford Friedenthal" To: "'Chonoles, Michael J'" , "'Rouquette, Nicolas F \(313K\)'" Cc: "'Juergen Boldt'" , , , "'BERNARD, Yves'" Subject: RE: 16016 -- QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd CommentRe: Ex: RE: SysML Issue on Refine limitations Date: Fri, 11 Feb 2011 12:04:29 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvJc88X0o2Y0MvoQC6e5Uq7cXNMXAAjwEQwAAKz4SA= Michael Can you propose the update that adds the derived properties to correct the issue and give us a two way refine relationship. Thanks. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Friday, February 11, 2011 10:54 AM To: Rouquette, Nicolas F (313K); Sanford Friedenthal Cc: Juergen Boldt; issues@omg.org; sysml-rtf@omg.org; BERNARD, Yves Subject: RE: 16016 -- QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd CommentRe: Ex: RE: SysML Issue on Refine limitations Nicolas, I not sure what you.re saying, however, there are still issue(s) 1) The SysML .refine requirement relationship. cannot be used both ways because we have not added the derived properties to requirements and namedelement (as we did with the other requirement relationships) to support this. The two refine relationships are not the same relationship. Therefore the SysML spec text must be corrected. 2) We can.t have a diagram refine anything. The SysML spec text must be corrected. Michael From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Thursday, February 10, 2011 5:43 PM To: Chonoles, Michael J; Sanford Friedenthal Cc: Juergen Boldt; issues@omg.org; sysml-rtf@omg.org; BERNARD, Yves Subject: 16016 -- QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd CommentRe: Ex: RE: SysML Issue on Refine limitations Michael, Sandy: I propose to resolve this issue as: no change. We should be aware that there is a UML «refine» relationship that can be used between any model element (and it may be bi-directional) This is incorrect. Per UML2.4, Figure C.1, UML::Refine is a stereotype extending UML::Abstraction, which is a specialization of UML::Dependency Per UML2.4, clause 7.3.12, the client/supplier of a UML::Dependency are UML::NamedElement. Therefore, a UML::Refine relationship be used between any model elements that are of kind UML::NamedElement. The UML::Refine relationship is unidirectional because UML::Dependency is a kind of UML::DirectedRelationship. All of SysML's requirement-related relationships in clause 16.3.2 of SysML1.2 are specializations of UML4SysML::Trace, which corresponds to UML::Trace, which is a stereotype extending UML::Abstraction, just like UML::Refine does above. Therefore, all of SysML's requirement-related relationships are perfectly compatible with UML::Refine stereotype relationship from UML2.4's StandardProfileL2. Please be careful with the term "model element" in the SysML specification. It is used in different contexts to mean different things. There is a "SysML::ModelElements" package that adds to the confusion in figure 4.3. In clause 16, the term "model element" is used loosely without precisely describing what kind of SysML-stereotyped UML4SysML it refers to. Note that the set of model elements that are a kind of UML4SysML::Element, are not abstract, are not a kind of UML4SysML::Relationship and *not* a kind of UML4SysML::NamedElement is precisely: QualifierValue Slot LinkEndDestructionData LinkEndData Image LinkEndCreationData Clause ConnectorEnd Comment The list above are the concrete metaclasses that we would be able to include in the requirement derived properties if we relaxed their type from UML4SysML::NamedElement to UML4SysML::Element Is this useful? No. Why? There is nothing in UML2.4 we can use to establish any kind of relationship between a SysML::Requirement and any of the above metaclasses unless it is by ownership (e.g., Comment or a property typed by one of these metaclasses). - Nicolas. On Feb 10, 2011, at 12:01 PM, Chonoles, Michael J wrote: Re:issue 16016 Yes, that.s also a possible fix. I picked the simpler one for the first proposal. Yves has also suggested we fix it to go the other way. We should be aware that there is a UML «refine» relationship that can be used between any model element (and it may be bi-directional) There doesn.t seem to be any relationship between the SysML «refine» and the UML «refine», and only the SysML refine requirement relationship can use the callout notation. It.s unclear whether the UML «refine» would be allowable in a SysML model. From: Sanford Friedenthal [mailto:safriedenthal@gmail.com] Sent: Wednesday, February 09, 2011 9:25 PM To: Chonoles, Michael J; 'Juergen Boldt'; issues@omg.org Cc: sysml-rtf@omg.org Subject: Ex: RE: SysML Issue on Refine limitations Michael We may want to fix this so that a requirement can refine a model element. Thanks for the catch. Sandy From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Sent: Wednesday, February 09, 2011 12:49 PM To: Juergen Boldt; issues@omg.org Cc: sysml-rtf@omg.org Subject: SysML Issue on Refine limitations The text description of how the refine relationship can be used disagrees with formal restrictions. On page 126, 2nd paragraph, the text says. .The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element.. This allows a refine relationship to be [Requirement] ß..*[Model element] Or [Requirement] à [Model element] However, Figure 16.1 only has /refinedBy:Named Element[*] as property for a Requirement Thus it is not possible to have a requirement refine a model element. This is confirmed by Figure 16.2, which in showing the tags for a NamedElement Has /refines Requirement [*] This is confirmed in table 16.2 by only showing paths that allow a NamedElement to refine a requirement (and not the other way around). So problem 1. The text and restrictions disagree, fix the text to be as follows, by deleting the last sentence: The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity diagram may be used to refine a text-based functional requirement. Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element. Problem 2 The text indicates the refine relationship may be from a diagram. A diagram is not a metaclass in UML or SysML and cannot participate in this way. Please strike the word .diagram. from the text Final wording The refine requirement relationship can be used to describe how a model element or set of elements can be used to further refine a requirement. For example, a use case or activity may be used to refine a text-based functional requirement. Additional comment. It.s unclear in these circumstances, to me at least, whether two different use cases that «refine» a requirement are participating in the same refinement relationship or are just stored in a common location in the requirement. Michael Chonoles LMCO DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=VaocBrMi17k58nTbIn78eGfGBCbHZ8GUWPqLI8cfzUc=; b=gPCuLMAssLliU+bM0qkKz0LX0FXNxYPp8H7ieNJ5YcPoQSvqoVw+30iiCVfrwI7yiZ UfkLkw0mgF0pmQwnrs7TcBmF8Qse8hSlHkwa3Gwq3YOdMEVcPRtvCnTzrDvUVnZdCZjJ 7mdVulf9UcsExQVZmpt4AleN+VY4aa3UZX3HA= From: "Sanford Friedenthal" To: Subject: Issue No: 16016 SysML Issue on Refine limitations Date: Thu, 16 Feb 2012 15:19:11 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Aczq6do722AeWa5sQq6PP+Ej2b4iOAABMyugABh0yTAAV8hrsAAN25BA Roger, SysML RTF The proposed resolution in Ballot 1 to Issue 16016 on the refine relationship removes the following text to get consistency with other parts of the spec: "Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element." By removing this text, we are no longer able to refine a model element with a text requirement, although we can continue to refine a text requirement with a model element. This limits our ability to use rich text statements to refine the model. For example, one may use a use case description as a requirement that refines a use case in a use case diagram. It is also used the other way around. My preferred resolution is to continue to allow the refine relationship to be used to refine a model element with a text requirement. This requires some other fixes to the section to address the inconsistencies. Sandy Subject: Re: Issue No: 16016 SysML Issue on Refine limitations X-KeepSent: 674C6064:B5C780A6-882579A6:0070AD83; type=4; name=$KeepSent To: "Sanford Friedenthal" Cc: X-Mailer: Lotus Notes Release 8.5.2FP1 SHF163 March 17, 2011 From: Fredrick A Steiner Date: Thu, 16 Feb 2012 12:33:40 -0800 X-MIMETrack: Serialize by Router on ES2-MSG01/SRV/Raytheon(Release 8.5.2FP2|March 22, 2011) at 02/16/2012 12:33:41 This issue was supposed to be "easy" or non-controversial. While I don't necessarily agree with Sandy's approach, I feel obliged to withdraw this resolution from the ballot. We can then take appropriate time to discuss it, and include a resolution in a future ballot. Cheers, -Rick Rick Steiner Raytheon Technology Networks 858.522.2008 (desk) 619.200.9467 (cell) Raytheon Certified Architect "Sanford Friedenthal" ---02/16/2012 12:21:25 PM---Roger, SysML RTF The proposed resolution in Ballot 1 to Issue 16016 on the refine From: "Sanford Friedenthal" To: Date: 02/16/2012 12:21 PM Subject: Issue No: 16016 SysML Issue on Refine limitations -------------------------------------------------------------------------------- Roger, SysML RTF The proposed resolution in Ballot 1 to Issue 16016 on the refine relationship removes the following text to get consistency with other parts of the spec: "Alternatively, it may be used to show how a text-based requirement refines a model element. In this case, some elaborated text could be used to refine a less fine-grained model element." By removing this text, we are no longer able to refine a model element with a text requirement, although we can continue to refine a text requirement with a model element. This limits our ability to use rich text statements to refine the model. For example, one may use a use case description as a requirement that refines a use case in a use case diagram. It is also used the other way around. My preferred resolution is to continue to allow the refine relationship to be used to refine a model element with a text requirement. This requires some other fixes to the section to address the inconsistencies. Sandy