Issue 2020: Guard in current metamodel can be replaced by Constraint with stereotype (uml2-superstructure-ftf) Source: (, ) Nature: Revision Severity: Critical Summary: Summary: The Guard metatype in the current metamodel contains only one attribute of type BooleanExpression. Since a guard is semantically equivalent to a Constraint on the transition, we can remove the Guard metaclass and add e standard stereotype <<guard>> for Constraints, with the same semantics. It simplifies the metamodel by unifying the Guard and Constraint concepts. It also allows OCL as the optional language to write the guard expression. Within the OCL specification, it should be checked if there are any additions that need to be made to support everything neded to express udseful guards. Resolution: Revised Text: Actions taken: September 30, 1998: received issue July 22, 1999: Deferred:UML 1.4/2.0 March 9, 2005: closed issue Discussion: This is merely a metamodel optimization transparent to a UML user and not a bug or inconsistency in the spec. Hence, it is out of scope for 1.5. It should be considered for UML 2.0. Resolved in UML 2.0, where a guard is now modeled as a Contraint (association from Transition to Constraint in the metamodel). End of Annotations:===== Return-Path: From: Jos Warmer To: , Subject: Issue for UML-RTF Date: Wed, 30 Sep 1998 08:14:31 +0000 ISSUE: Description: A Guard in the current metamodel can be replaced by a Constraint with stereotype <> Severity: Major Nature: revision Responsibility: OWG/SMWG Status: Reference: OCL Specification Summary: The Guard metatype in the current metamodel contains only one attribute of type BooleanExpression. Since a guard is semantically equivalent to a Constraint on the transition, we can remove the Guard metaclass and add e standard stereotype <> for Constraints, with the same semantics. It simplifies the metamodel by unifying the Guard and Constraint concepts. It also allows OCL as the optional language to write the guard expression. Within the OCL specification, it should be checked if there are any additions that need to be made to support everything neded to express udseful guards. Comments Proposal Resolution ________________________________________________________________________ Jos Warmer IBM, Object Technology Practice OTP Leader Netherlands OCL home: http://www.software.ibm.com/ad/ocl private tel : +31 (0)35-6037656 work tel: +31 (0)79 322 7933 private fax : +31 (0)35-6037647 work email: jwarmer@nl.ibm.com mobile: +31 (0)6 53428821 http://www.klasse.nl/Engels/jos.htm Return-Path: From: "Rodolphe ARTHAUD" To: "Jos Warmer" , , Subject: Re: Issue for UML-RTF Date: Fri, 2 Oct 1998 12:02:12 +0200 X-Msmail-Priority: Normal X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 -----Original Message----- From: Jos Warmer To: uml-rtf@omg.org ; issues@omg.org Date: Wednesday, September 30, 1998 11:03 AM Subject: Issue for UML-RTF >ISSUE: >Description: A Guard in the current metamodel can be replaced by a >Constraint with stereotype <> I think this proposal should not be accepted. All a GUARD and a Constraint have in common is that they are both boolean conditions. But a constraint is a specification item defining the integrity of the system, whereas a guard states the actual behavior. This has several consequences, like the fact that: * a guard should be constrained by scope rules (it must be expressed in terms of what is visible from the state machine in a given context, like the object's atributes of the current signal's parameters), whereas * a constraint may be expressed in terms of any global property of the model accessible to the modeler (like, say, the total number of instances of a given class). In other words, a guard says "check this, trigger transition if true". A constraint is an invariant saying "this must be true (not checked) at al times". However, OCL can be used to specify a guard: I suppose that BooleanExpression is an uninterpreted string anyway. Your proposal: <> for Constraints, with the same semantics. It simplifies the metamodel by unifying the Guard and Constraint concepts. It also allows OCL as the optional language to write the guard expression. Within the OCL specification, it should be checked if there are any additions that need to be made to support everything neded to express udseful guards. >> _______________________________________________________________ Rodolphe ARTHAUD, Senior Consultant, VERILOG //Integrated Solutions for Technical and Real Time Applications Tel : +33 (0) 5 61 19 29 54 150 rue Vauquelin : +33 (0) 5 61 19 29 39 BP 1310, 31106 TOULOUSE, FRANCE Fax : +33 (0) 5 61 40 84 52 Email : arthaud@verilog.fr http://www.verilogusa.com mailto: info@verilog.fr http://www.verilog.fr Return-Path: From: Jos Warmer To: Cc: , Subject: Re: Issue for UML-RTF Date: Mon, 12 Oct 1998 08:00:21 +0000 jos> Rodolphe, let's discuss this a bit further. I think that the notion of Constraint in the UML is broader then you might see right now. Please respond to arthaud@tlse.verilog.fr To: issues@omg.org, uml-rtf@omg.org, Jos Warmer/Netherlands/IBM@IBMNL cc: Subject: Re: Issue for UML-RTF -----Original Message----- From: Jos Warmer To: uml-rtf@omg.org ; issues@omg.org Date: Wednesday, September 30, 1998 11:03 AM Subject: Issue for UML-RTF >ISSUE: >Description: A Guard in the current metamodel can be replaced by a >Constraint with stereotype <> I think this proposal should not be accepted. All a GUARD and a Constraint have in common is that they are both boolean conditions. But a constraint is a specification item defining the integrity of the system, whereas a guard states the actual behavior. This has several consequences, like the fact that: * a guard should be constrained by scope rules (it must be expressed in terms of what is visible from the state machine in a given context, like the object's atributes of the current signal's parameters), whereas * a constraint may be expressed in terms of any global property of the model accessible to the modeler (like, say, the total number of instances of a given class). In other words, a guard says "check this, trigger transition if true". A constraint is an invariant saying "this must be true (not checked) at al times". jos> There is a strong difference between a Constraint and an invariant. What is stated above is true for invariants. The UML metamodel defines three standard stereotypes of Constraint: <>, <> and <>. Pre- and postconditions are not true at all times, neither do they state anything about well-formedness of a model. The confusion might be due to the fact that within the UML metamodel istself, we have used OCL only for <> Constraint (wellformednes rules), defining the integrity of the system. However, OCL can be used to specify a guard: I suppose that BooleanExpression is an uninterpreted string anyway. jos> In fact this is what I really want to propose. jos> The <> Constraint is conceptually very close to a Guard. It states something abut the runtime behavior using a booleanExpression. The BooleanExpression is evaluated at the moment the operation is triggered, and if it is true, the operation will fullfill its postcondition. Otherwise it won't. (or does not have to) jos> A Guard is very much like this. It act as a precondition on a transition. It is evaluated when the event happens, and depending on the result value the transition wil either fire or not. jos> In general, A Constraint is a restriction on things in the runtime system. Within this definition a Guard might be a special kind of constraint. jos> The visibility of objects that can be used within a guard is something we need to define carefully. Even without changing Guard to a stereotyped Constraint it is usefull to define this scope explicitly. For Preconditions and Postconditons the scope has also been defined to include the parameters of the operation. Something along these lines needs to be done for Guard. Your proposal: <> for Constraints, with the same semantics. It simplifies the metamodel by unifying the Guard and Constraint concepts. It also allows OCL as the optional language to write the guard expression. Within the OCL specification, it should be checked if there are any additions that need to be made to support everything neded to express udseful guards. >> _______________________________________________________________ Rodolphe ARTHAUD, Senior Consultant, VERILOG //Integrated Solutions for Technical and Real Time Applications Tel : +33 (0) 5 61 19 29 54 150 rue Vauquelin : +33 (0) 5 61 19 29 39 BP 1310, 31106 TOULOUSE, FRANCE Fax : +33 (0) 5 61 40 84 52 Email : arthaud@verilog.fr http://www.verilogusa.com mailto: info@verilog.fr http://www.verilog.fr ________________________________________________________________________ Jos Warmer IBM, Object Technology Practice OTP Leader Netherlands OCL home: http://www.software.ibm.com/ad/ocl private tel : +31 (0)35-6037656 work tel: +31 (0)79 322 7933 private fax : +31 (0)35-6037647 work email: jwarmer@nl.ibm.com mobile: +31 (0)6 53428821 http://www.klasse.nl/Engels/jos.htm