It is possible to use xs:choice element inside xs:sequence,
<xs:sequence>
<xs:choice>...</xs:choice>
</xs:sequence>
but not inside xs:all. Why is that? Does that create some ambiguity when parsing xml?
This can only really be answered by the designers of XML Schema. You could pose it to the XSD newsgroup (xmlschema-dev#w3.org). My guess is that ambiguity and/or complexity are the problem.
For example of an ambiguity, consider having an all group with two children that are choice groups and each of those has an element named 'X', of two different types. When an X element is encountered by the parser, which X is it: the one belonging to the first choice group or to the second choice group (note that it does matter, because you must know which type to validate it with)? Perhaps the designers could have specified constraints to avoid such ambiguities, but perhaps doing that was just too complex and not worthwhile.
Related
Trying to implement a class diagram and I am not sure how should it done properly. Here is the problem:
Miners can extract gold, silver and coal (the mines are homogeneous, always contains one type). In addition, there are some dangerous mines: e.g some might collapse or be radioactive.
How can I represent this on a class diagram? First, I thought it can be done with one Mines class. From that with generalization I candefine the collapsible and radioactive mines. But I can't decide how to deal with the different material types. Should that be classes too or attributes in the Mines class?
The simpler the better. Without specific behavior in the statement depending on the extracted substance it is enough to have only one class Mine, and the the list of possible substances being known an enumeration is enough. Because a mine produces only one substance the multiplicity is 1.
The statement doesn't say if the mine can both be radioactive and collapse or not.
Supposing a mine can both be radioactive and can collapse, you can use an attribute for each danger:
It is also possible to use a enumeration for the danger and the multiplicity 0..2 but it is also necessary to have a constraint saying each danger appears at most one time, so this is not a simple way.
Else if even less probable a mine can have at most one danger you can again use a enumeration with the multiplicity 1:
or with the multiplicity 0..1:
The best way to model this is by defining the material in the mine as an enumeration. An enumeration is a data type, which you can use to define an attribute, as follows:
The dependency arrow from Mine to Material is redundant, because it is already implied by the fact that it is used as an attribute type, but in a more complex class diagram, I find it helpful to easily see which enumerations are used by which classes.
I did not use generalization for the various types of mines, because the subclasses would not have special features, so I go for the most simple solution.
I did not use generalization for the dangers, because a mine may be both collapsing and radioactive.
In UML class diagram, is it possible to represent an attribute that can have multiple types? For example, MyClass has an attribute named MyAttribute. How can I specify in class diagram that MyAttribute can assume float or string type value? An alternate option is to write MyAttribute: (https://learn.microsoft.com/en-us/visualstudio/modeling/uml-class-diagrams-guidelines?view=vs-2015), i.e. not specifying the type, but not specifying the type may create problems if people start to use their own types.
Thanks in advance.
One way to do this is to model a union of two different data types. You would define a data type that has two specializations, create a generalization set that is {complete, disjoint}, make the general data type abstract, and use the general data type as the attribute’s type.
You may have trouble convincing a code generator to map this correctly to a programming language, such as C++ or XSD, which can both represent this construct, but the UML would be perfectly clear to any reader.
A UML Attribut or Property can only have one type.
So if you want, for example, to allow both String and Float values you have to type your attribute with an Interface common to both of them like Object for example.
But of course, it will less precise because you allow other kind of values....
When you're dealing with untyped languages (like e.g. Python), none of your attributes have a specific type. In any typed language you decide at compile time which type an attribute can take. I don't know of any language that allows a set of types to be assigned to any attribute.
Assuming you're talking about untyped languages, you would add a constraint to your generally untyped attributes telling something like { must take either type A or B }. Of course, the compiler/interpreter will not help you in checking that constraints.
Let's say I have class A with associations to classes X, Y, and Z, respectively. I need to indicate that only one of these associations may be instantiated for any given instance of class A (so, an xor constraint). I know how to do this if the constraint is just across two associations. Obviously I can just make three seperate xor constraints (X-Y, X-Z, Y-Z) but I'm wondering if there is a better/cleaner/proper way to do it?
edit: The multiplicity constraints on the respective associations are not the same. Using an abstract class or interface will not work. Furthermore, a note is insufficient. I need to use some sort of formalized structure, preferably something standardized (e.g. by OMG) to express this because I am programmatically processing the model elements (i.e. it isn't just a picture). I understand how the underlying model for UML provides for this facility. It also specifies (though slightly vaguely) how it should be notated. I guess my main issue is, in fact, with finding a tool that allows me to make that notation. I don't think MagicDraw does so. I should have stated these things earlier.
FWIW, I'm using MagicDraw. It would be a nice bonus if the I could do this in a way that MagicDraw actually understood. I can live with it if that isn't possible.
The xor constraint is just a stylized and rather under-specified constraint for the 2-way case.
You can define an explicit constraint (in Complete OCL) as:
context A
inv OnlyAorBorC: A->size() + B->Size() + C->size() <= 1
MagicDraw may allow you to specify a similar contextual Constraint on A.
If "X", "Y" and/or "Z" can be somehow generalized (I mean, if you not doing this puraly for a conditional flow control), you can make an interface (or and abstract class) "I" for example, and make "X", "Y" and "Z" implement this interface. Then, you put an association with multiplicity 1 between A and the interface I.
See the diagram below:
Edit: The example above doesn't work in the case of A having different cardinalities between X, Y and Z. For this case, the only way that I can see is use an UML Constraint to restrict those relationships. You can define a Constraint in UML putting some OCL expression between curly braces. E. g.
Here, account owner is either Person or Corporation and this {xor} is predefined UML constraint.
I'm not sure about the details of your cardinalities requirements but, a combination between this {xor} and the interface example that I gave might be enough. At least it gives you a little bit more of options, like:
If you need to know more about the UML constraints subject, I got this example from uml-diagrams.org: http://www.uml-diagrams.org/constraint.html
Let's say I have class Foo that has an association to some thing(s) that fulfill(s) a role. This role could be fulfilled by either (strictly) one Bar xor any number of Baz. Similarly, the role might be fulfilled by either any number or Bar xor any number of Baz (but a mixed collection is intolerable). Are there reasonable ways to represent these in a class diagram using only associations, classes, and interfaces? I would (really) like to avoid using OCL or constraint elements.
(The reason I would like to avoid these is because we are generating code from our UML. We have already implemented generation that handles associations, classes, and interfaces. Dealing with OCL would be quite the task. Constraint elements wouldn't be so bad but still quite a lot of work.)
I would start with the picture below and create several different versions before deciding which one generates best code (junior-40).
The yellow blocks represent necessary "glue code" needed to straighten your example against your other requirements
Consider creating an abstract class Thing and derive Bar and Baz from it. It abstract the whole role, can contain some own atts and methods if needed and is quite flexible and extendible.
Now Account has an association only with AccountOwner (role "role", as Jim L. has explained in his comment, a role name must be unique in this context).
Note that this does not eliminate the need of some additional restrictions. For example, all linked "roles" should be of the same type. Sometimes is not easy (or even possible) to remove all restrictions. Otherwise we would make complete systems out of class diagram. I agree though, that as much information as possible should be contained in classes, their taxonomies and features (atts, assocs and methods).
EXAMPLE:
EXAMPLE 2 (after comments):
This version overcomes the need to use OCL ant yet keeps the simplicity and flexibility:
Multiplicities are now also derived and refined for each concrete "role". No OCL needed. :)
You add a constraint on the class in OCL:
(self.role->exists(r|r.oclIsType(Bar)) and self.role->notexists(r|r.oclIsType(Baz)) ) or
(self.role->exists(r|r.oclIsType(Baz)) and self.role->notexists(r|r.oclIsType(Bar)))
You can try this out with MDriven Designer.
The reason for introducing OCL (object constraint language) in the UML specification was just this; ability to add constraint not possible or practical to convey with simple cardinality and type information
Could this image help you ? It is extracted from the norm.
Are you thinking of something like the following:
(source: uml-diagrams.org)
Where Account is your Foo, Person is your Bar, and Corporation is your Baz.
You can then specify multiplicity on each of the two associations: [1] for Bar (Person) and [1..*] for Baz (Corporation).
I have some types with a sequence inside, which does restrict the order of child elements. I want to remove these order restrictions. Which element should I choose, assuming that I can't (or don't want) change definition of child elements?
For example, if I'd change with <xs:choise maxOccurs="unbounded"> it won't be full equivalent of <xs:sequence>, because some child elements which initially supposed to appear only once, could appear now several times.
And vice-versa, I can't use xs:all, as now I'll have a restriction on maximum amount of elements (no more than 1).
So, is there simple and quick solution? (to make as few changes to schema as possible)
Short answer is you can't.
An option would be to define a type for each combination of node sequences which are possible and then enclose them in an but this would be faintly ridiculous.
You can wrap the <sequence> in a <choice>.
<choice>
<sequence>
<!-- list your choices here -->
</sequence>
</choice>