In the example I made every object of the type "Folder" have an array of type "File" with the name "content" a size of "n" as a private attribute (just saying my understanding of it to make sure that I am not already wrong there). That's how I see it in most examples but I never understand what "n" now is. Is it another attribute of the "Folder" object or is it something that we specify in another part of an UML diagram or something else completely?
What I am trying to achieve is that every object of the type "Folder" has an additional attribute that specifies the size of the "content" array.
Of course, you can not only write 0..*, but use any concrete number, too. If that number has some external definition, you can use there n, as you have it.
The external definition means "not defined by class diagram elements, except notes". Everything that you need to be said on a class diagram page, but can't because of the UML limitations, should be put in a note.
So, n can be defined in appropriate note on the page or in some different document or both.
As #Kilian had mentioned, in the case of some more complicated dependencies of such variables you can use constraints. This way seems to me the most powerful.
But if n has no objective definition or dependency, but is a simple variable that can have any meaning, then it will be correct to use a rule, such as 0..*, or 1..*, or maybe 3..5, according to the reality you are working with.
Related
I have a child class which wants to add more functionality to a base class function, how can I represent that it also does the base class function not just the newly added functionality?
Interesting question. I tried that with Enterprise Architect. It did let me select the parent's operation but the display in the diagram did not change. It seems like you need to use notes for that:
As you can see Class2 inherits from Class1. The SD shows a call to Class2's operation a(). The call to the super-class's Class1.a() as internal call shows the same signature. A note clarifies the situation.
Maybe there's something else possible with this. But that's what I came up with immediately.
P.S. I've looked up the specs. P. 575 of UML 2.5 says
The message-name appearing in a request-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation or Signal referenced by the signature. Otherwise the name is unconstrained.
That would put in the option to specify the operation in question as Class1:a() or the like. Actually Enterprise Architect shows it that way in the properties of the message but shortens it to just the basic name. Just a border case, I'd guess.
I have a child class which wants to add more functionality to a base class function, how can I represent that it also does the base class function not just the newly added functionality?
Interesting question. I tried that with Enterprise Architect. It did let me select the parent's operation but the display in the diagram did not change. It seems like you need to use notes for that:
As you can see Class2 inherits from Class1. The SD shows a call to Class2's operation a(). The call to the super-class's Class1.a() as internal call shows the same signature. A note clarifies the situation.
Maybe there's something else possible with this. But that's what I came up with immediately.
P.S. I've looked up the specs. P. 575 of UML 2.5 says
The message-name appearing in a request-message-label is the name property of the Message. If the Message has a signature, this will be the name of the Operation or Signal referenced by the signature. Otherwise the name is unconstrained.
That would put in the option to specify the operation in question as Class1:a() or the like. Actually Enterprise Architect shows it that way in the properties of the message but shortens it to just the basic name. Just a border case, I'd guess.
I want to express the xs:choice element from XSD in OWL:
XML Schema choice element allows only one of the elements contained in the declaration to be present within the containing element.
I think maybe I should first define a property group in OWL, and then specify only one of the properties in the group is allowed exists. Any help?
I think maybe I should first define a property group in OWL, and then
specify only one of the properties in the group is allowed exists. Any
help?
There's no notion of "property group" in OWL, but you could get a similar effect using subproperties and disjoint properties. For instance, you could have a property hierarchy like this:
hasVehicleChoice
hasCar
hasTruck
Then, you can declare that hasCar and hasTruck are disjoint. That means that a individual can't have the same value for both properties. That means that you can't say:
x hasCar vechicle72
x hasTruck vechicle72
That's not enough to say that they can't have different values though. You could still have
x hasCar vechicle72
x hasTruck vechicle75
To avoid that, you could make hasVehicleChoice be a functional property (meaning each individual has 0 or 1 values for it, but no more), or use a subclass axiom with a restriction, like
Person subClassOf (hasVehicleChoice exactly 1)
Then, each person would have exactly one vehicle choice, and since hasCar and hasTruck are disjoint, the person can't have both.
All that said, this isn't a common pattern in OWL ontologies, and there's not a particularly convenient way of encoding it. If you don't need it all that often, you might be better off just using the subclass axioms and property restrictions directly. E.g.,
Person subClassOf ((hasCar exactly 1) and (hasTruck exactly 0)) or ((hasCar exactly 0) and (hasTruck exactly 1))
I know that there are ways to access an EAttribute of an Eclipse EMF model by its featureID or by its name via different indirect approaches. For that I found the following: Eclipse EMF: How to get access EAttribute by name?
But what if I don't know the name of the attribute I want to get? Let's say, based on the design, the model has some fixed attributes by the developer, along with the features that can be set dynamically by the user.
So, for the time being I use the getEAllStructuralFeatures() and use indexes via get() to reach to the by-the-user-created attributes, since I know that the list I get will have the fixed attributes of the model as its first elements beginning with the index 0. But I find this solution unclear and inefficient. Also in some cases, that I want to work, not suitable.
E.g: IEMFEditProperty prop = EMFEditProperties.list(editingDomain, EMFMODELPackage.Literals.EMFMODEL.getEAllStructuralFeatures().get(X));
Do you know a solution or a workaround for this problem? As far as I can see, there are no direct methods to get such dynamically created features of the model.
Every help will be appreciated.
I have been working on a similar case recently where I first tried to define an EStructuralFeature to access exactly the setting/attribute of the object that I needed.
But if you look at how things work internally in ECore, you will find out, that there is no way this will ever work, since the indices are bound to the object identity of the EStructuralFeature objects created at runtime for the specific context (i.e. EClass instance).
My approach was then to either inspect the features proposed by EClass.getEAllStructuralFeatures or to iterate over the features and inspect the object returned by EObject.eGet for this very feature (where EClass eClass = eObject.eClass()).
Example: In a UML profile I have defined a UML Stereotype called "Bean" with a property called FactoryEntity. The property shall reference a UML Class with the Stereotype "Entity" that is closest to this very bean and for which a static factory method will be generated.
In the model I would then have one UML Class typed as Bean and one as Entity.
And for the Class typed as "Bean" I would then set a value for the attribute/property factoryEntity defined in the profile.
The question was then how the property value would be accessible in ECore. I ended up iterating the List of available EStructuralFeature of the EClass of the EObject and checking the type of the object returned by eGet.
final EObject eObject = (EObject) holdingClass.getValue(stereotype, stereoTypePropertyName);
final EList<EStructuralFeature> allEStructFeats = eObject.eClass().getEAllStructuralFeatures();
for(EStructuralFeature esf : allEStructFeats)
{
final Object o = eobject.eGet(esf);
if(o instanceof org.eclipse.uml2.uml.Class)
{
return (org.eclipse.uml2.uml.Class) o;
}
}
Maybe that is not the most elegant way to access structural features but it is the only one I thought was robust enough to last.
Please let me know if you have any suggestions on how to improve this.
My XML files have restrictions on the child elements, but it really doesn't matter what the name of the root element is. How can I incorporate this into my XSD? I've tried using <xs:any> but I get:
"S4s-elt-invalid-content.1: The Content Of 'schema' Is Invalid. Element 'any' Is Invalid, Misplaced, Or Occurs Too Often."
So I tried missing the name off the element tag like this: <xs:element> but then I get:
"S4s-att-must-appear: Attribute 'name' Must Appear In Element 'element'."
Use a named type, and tell your validator to start validation at the root element using that type.
(There is one possible hitch with this: XSD 1.0 suggests that as one possible invocation option, but does not require validators to provide it, so there's no guarantee the validator interface you use will support it. Depends on your validator. Worth trying, at least.)
Another way to put this: you already have what you are asking for, because your XSD schema never cares what the root element of your document instance is called. An XSD schema provides a set of element and type declarations (among other things). A validator can be requested to start the validation at any point in the document, not just the root, and with either an element declaration or a type declaration, or in 'lax wildcard mode' (the most common default). If your validator doesn't offer the invocation options you want, it's a flaw in your choice of validator, not a gap in XSD.
I think I might just make the requirement stricter and insist on using a particular tag as the root element. The fact that the application doesn't care is not really a problem.
It seems (to me) strange that this limitation exists, but I am new to XSDs.