In the UML, a Property is an association end and can be owned either by the association or by a participating Classifier, which is typically a class. When a Property is owned by a class, it's called an attribute. For example, an attribute Book::author could get one of the following notations (where a dot should be drawn at the author association end of the right-hand side diagram):
The attribute could be used in constraint expressions like: self.author or mybook.author->count()
This is straightforward for binary associations. But I have doubts how this works with ternary (or more generally N-ary) associations, for example:
Is it correct to state that Project would have an attribute participant and an attribute role since these are the opposite member ends of the association?
And considering that participant and role are not independent, how to make use of their correlation in constraints, for example to refer to the contributors having a given role, or to the set of (participant,role)-tuples to constrain its ->count() to less than 10?
Of course, in your example, attributes like Project::participant or Project::role do not make any sense for representing ternary links.
The UML spec (in 11.4.3.1 Classes) states that
Attributes of a Class are Properties that are owned by the Class. Some of these attributes may represent the ends of binary Associations.
They don't mention the possibility of attributes as ends of non-binary Associations.
In 11.5.4 (page 202), as pointed out by #Christophe, they say
Ownership of Association ends by an associated Classifier may be indicated graphically by a small filled circle, which (...) we will term a dot.(...) The dot shows that the model includes a Property of the type (...). This Property is owned by the Classifier at the other end.
The important concept here is "the other end", which is also called "the opposite end" in other statements of the spec. It implies that there must be a unique other end of the association.
Consequently, since Attributes are association ends (= Properties) owned by the Classifier at the opposite end, they can only be the ends of a binary association.
This implies that for n-ary associations, the participating classes cannot own any end and can therefore not have (reference) attributes like Project::participant.
Also, using common sense: what would be the possible meaning of an attribute like Project::participant (or better: Project::participants)? It could be intended to represent the collection of all Contributor objects that participate in an instance/link of the ternary association Project-Contributor-Role. This could be defined as a derived attribute using an OCL expression. But it does not allow to represent/implement/reconstruct the ternary association.
In OOP, you could have a property like Project::contributorByRole the values of which would be ordered pairs from the Cartesian Product of Contributor and Role. Such a property represents/implements the ternary association. But, afaik, UML does not define Cartesian Product types and does, therefore, not support such tuple-valued properties.
For n-ary associations all ends must be owned by the association and thus, they are not attributes.
There is a constraint in section 11.8.1.8, so, it is as clear as it gets:
association_ends
Ends of Associations with more than two ends must be
owned by the Association itself.
inv: memberEnd->size() > 2 implies ownedEnd->includesAll(memberEnd)
Related
I have read that derived types are completely different types than their respective parents, however the do inherit all their parents' operations.
In other words, you can pass a derived type A to a operation that receives as a parameter a type B which is A's parent. However, you can't assign a variable of type A to one of type B and vice versa.
According to the above, the only difference between derived types and subtypes is the assignment. Is that right?
Derived types only inherit the primitive operations of the type they are derived from.
Technically the type derivation creates a new set of primitive operations, so you can't "pass a derived type A to a operation that receives as a parameter a type B which is A's parent". But the compiler creates operations of the same name and implementation, which work on type A from the primitive operations of type B. You can for example remove the inherited operations by explicitly declaring them abstract.
In AX2009, how is it possible to find the table that is related to an InventTransType in the code?
For instance, InvnetTransType::Sales is related to the SalesTable, but how is it possible to get the table id or table name from SalesTable in the code?
I do not think this is possible, because there is no 1:1 relationship between the elements of the InventTransType enum and tables. At best there is a 1:n relationship (e.g. you could argue that InventTransType::Sales is related to table SalesLine just as well or even better as table SalesTable). Note also that the documentation on the enum says that it specifies "the module that generated the transaction".
It really depends on the question you ask and the data you want to retrieve. That said, here are some points you could research, maybe one of them fits your question/requirements. If all else fails, you can always write your one mapping method that takes an enum element and gives you the id of the table you think is appropriate for this element(standard AX does this in several cases to map other entities to the enum elements, see for example table InventDimSetup, method transType2FieldId).
cross references: check the cross references of the enum or of an enum element, that should give you an idea which table(s) are associated with which element
relations of table InventTrans: for some of the enum elements, you can find table relations in table InventTrans (but unfortunately not for all of them); ponus point is that by using reflection, you can analyze the relations and get the referenced table (which is probably as close to your requirement as it can get in standard AX)
In Oracle ADF, you can create a validation rule (Key Exists) that checks the existence of a key in another entity attribute, but you must have an association defined to the destination entity.
Also, it is possible to define an entity constraint that references another entity's attribute, but it only requires the referenced attribute to be a primary key.
Effectively, how are they any different from each other?
Is it an abundance of choice, or is there an intrinsic difference that I should learn about?
Having an association allows you to not just do validation but also access one EO from the other, and manage the way data in this master-detail relationship is inserted into the database. (read about composite associations for more).
I need to create a fairly complex rule in Drupal - I am willing to use either code or the interface to do so.
I am more familiar with the interface, however, as opposed to the Rules API.
Anyway, the rule will be as follows:
It will happen based on a form submission from entityforms (which is one entity). It will take the checkbox value of a field (not just the true or false, but rather the value submitted when a value is true or false). It will convert this number to an integer.
At this point things get interesting - I want to create a new entity of registrations (a different entity), which as far as I can tell, means I'll have to bring a registration into scope. I also need to bring node (and not just node: type and other data selectors, but specifically node) into scope, because the next step requires it.
So at this point, I should have three entities loaded into scope:
entityforms
registration
node
I believe the best way to bring registration into scope would be entity is of type? The documentation page says that content of type should be appropriate - but that seems like it might be related to the specific use case of the example - not in my more complex example where registration isn't the first entity dealt with, but rather a second.
https://drupal.org/node/1463042
So anyway, if all three of these entities is called in correctly, the ultimate result should be the following:
Value from boolean field (not the straight 1 or 0, but whatever the value to be submitted is switched to) from the entityform is converted to an integer, and inserted where entity host ID is required. In the section where host entity type is the value should be node.
I am also open to alternative suggestions if this seems overly complex or poorly architected.
The Host Entity Type cannot be of Entityform? Why be a Node since a Registration can be attached to any entity? Then you will get the id of the Entityform as also as any other fields from that entity type instead of Node. Next steps are the same.
As a reference, the most similar question already asked is: https://stackoverflow.com/questions/8667849/making-xforms-enforce-the-constraint-and-type-model-item-properties-only-when-fi The difference is that I cannot use the 'relevant' property since I do want the field to be visible and accessible.
I'm attempting to make an XForms form that has the following properties:
It displays a text field named 'information'. (for the example)
This field must not be required, since it may not be necessary to enter data. (Or this data will be entered at a later time.)
However, if data is entered in this field, it must adhere to the specified constraint.
I cannot mark the field as not relevant since this would hide the field and some data may need to be entered in it.
The trouble now is that even though the field has no data in it, the constraint is still enforced (i.e. even though it is not marked as 'required').
I have taken a look at the XForms 1.1 specification, however it does not seem to describe how the properties 'required' and 'constraint' should interact.
The only option I see, is to add a part to the constraint such that an empty value is allowed.
e.g.:
. = '' or <actual-constraint>
However, I don't like this. It feels like a workaround to add this to every such field.
Is there any other way to express that non-required fields should not need to match the constraint for that field? (Am I missing something?)
In XForms 1.1, required serves two purposes:
mark the field as required (implementations can style controls to reflect this, e.g. with a "*")
take part in the validation process
The latter is described in 4.3.3 The xforms-revalidate Event.
An instance node is valid if and only if the following conditions hold:
And one of the conditions is:
the value is non-empty if the required model item property is true
So it is a logical and between all aspects that impact validation.
I can see how things could have been different, e.g. saying required="false()" could disable the rest of the validation. However that's not the approach XForms is taking.
Based on this there is nothing wrong checking for emptiness as part of the constraint.
XForms 2.0 might add custom XPath functions, which might help with reuse of logic:
<bind ref="information" constraint="my:constraint(.)">
Also, if the constraint can be expressed with a type, you may be able to use one of the schema types in the XForms namespace, which allow empty values to be valid. For instance xforms:double considered the empty string and 42 to be valid values, but not gaga.