Can I access what in Protege is called "general class axioms" of an ontology via owlready2? Those containing named and anonymous classes, like in the screenshot:
enter image description here
I stumbled upon method ontology.general_axioms(), but the output is quite weird: a list of expressions and restrictions. It was not what I was expecting because I could not find how the elements of the list relate to each other. Also, I did not find all the expressions I created in Protege.
Related
I have defined a generic interface using Enterprise Architect (see figure below).
I would now like to specify the following realization:
class AircraftsTypesRepository implements Repository<AircraftTypes, Integer>
Is there a way for EA to automatically bind types and method signatures to the generic types I specified in the base interface. In other words, I would like to show in the diagram that for the AircraftTypesRepository class, T and K and bound to T=AircraftTypes, and K=Integer. I would also like to see this reflected in the interface methods
I thought about this and (as there's no native support) would suggest to script that. There are plenty of ways, so I'd take a KISS one. The Realize relation could be adorned with tagged values named Bind<val> or so where <val> is the name of a template parameter (in your example T or K). These TVs should then be defined as RefGUID which allows them to link to an EA element. Creating these TVs should be one script which looks into the templated class. You find the template definition in the table t_xref with
SELECT description FROM t_xref
WHERE client = `<GUID of element>` AND type = `elment property`
This will contain something like
#ELEMENT;GUID={5EC3D8DF-BC37-4529-8F36-0D9BA363955D};Name=E;Type=ClassifierTemplateParameter;Pos=0;#ENDELEMENT;;
(I created an example with just T but you will decode it easily, I guess.)
Now that you have the tagged value(s) set in the Realize you can run a second script to synch the definition ("just" look for textually identical types). Later you could alter the TVs and re-synch again (AFAIK there's not hook for TVs being altered so that needs to be triggered manually).
This is not a complete solution but just a suggestion which leaves open quite some field for experimentation (and failure).
I have two classes (say Database and Record). In Database class, I have a method named getRecords() that returns a list of Record objects.
In Java, the above method can be written as:
List<Record> getRecords(){..}
In StarUML, while designing Class diagram, I tried giving
+getRecords() : Record[0..*]
But StarUML refused to create method like above. When I tried with the one below, it works
+getRecords() : ArrayList<Record>
But this is more specific to Java. I want to implement something like Record[0..*] in StarUML. Is it possible to write methods in such format or the Java style of return type is the only solution ?
I don't know why StarUML refuses to parse the text, but you can still create it via model.
Add the operation and call it getRecords()
Right-click on the operation (in diagram or model), and select Add > Parameter
Select parameter in Model Explorer (probably the parameter is already selected when you created it) and set the direction parameter to return. This is how UML represents return types.
(Configure the type, multiplicity, and anything else you need.)
Note that the default collection in UML is Set, so you should check isOrdered, as List is an ordered collection.
Backround to the problem: I have connected two classes to each other in UML, both of them being regular classes and one of them is named "League".
In the "miscellaneous" menu in MDriven, I found that the following “EffectiveName": "League_children” as well as "OtherEnd": "League_parent".
This was confusing in three ways:
There is not a class named "League" in "OtherEnd"
The terms "League_children” and "League_parent" were created automatically
It says "League_children" not "LeagueChildren" with the latter one I thought was more correct becuase of how you write in code, and also everywere else in the diagrams and menus in MDriven's workspace.
I read about the terms "children" and "parent" in the official book (https://www.capableobjects.com/xdownloads/MDrivenTheBook/MDrivenTheBook-Part2-Design.pdf ) and obviously these are used when you have superclasses and subclasses to those. However, neither "League" or any other class in my diagrams as of now are superclasses", so why are these names created then?
Furthermore, "OtherEnd" is not called "League" and therefore shouldn't have be called "League_parent".
I searched through my different classes and found no hidden associations that I had acidentally/falsely deleted.
I recognize the _Parent _Children pattern as what MDriven does when adding an association from a class back to the same class.
If you check the Class in the tree I bet you will find an association pointing back to self. If this was added by mistake - delete it.
Normally MDriven leaves the name of association ends blank - then the effective name will be the name of the Class in the end. Name - if set - overrides this.
When creating associations back to self - MDriven sets the names of the ends appending _Parent and _Children.
If I have an org.eclipse.jdt.internal.compiler.ast.FieldDeclaration, how would I check if the type of the field implements an interface, let's say Serializable? I don't see any documentation for org.eclipse.jdt.internal.
I found extract interface that a class implementing using AST parser, but that one talks about org.eclipse.jdt.core.dom.FieldDeclaration.
EDIT: At first I didn't look at the package and thought you were asking about org.eclipse.jdt.core.dom.FieldDeclaration. That's what the answer is good for.
If you need to work with internal classes, we expect that you know exactly what you are doing. There won't be any documentation for those (but conceptually the same approach as shown for the public API can similarly be used for the internal AST and bindings, too).
Type compatibility is best tested using the corresponding bindings, so your quest would consist of theses steps:
From the FieldDeclaration obtain the binding using resolveBinding()
From the field binding retrieve the type binding
Once get a binding representing the expected super type Serializable
Ask the actual field type isSubTypeCompatible(serializableType)
You'll find some more details - in particular on (3) - in a recent discussion in the JDT forum.
I'm newbie in MagicDraw and I'd like to know how to specify a class as {abstract}.
I know about de property "Is abstract" in the Specification of Class, but I'd like that it appears in the header.
The place where you set isAbstract in MagicDraw is in the specification window for the class. To open that window, either right-click on the class or press enter while it is selected. The window will look like this:
You didn't specifically ask for more information, but I'll provide it in case you find it helpful.
The model you want to create will look like this:
Notice that Abstract Class is written in italics to indicate it is abstract. Also notice that {complete, disjoint} is specified for the generalization set. (Just FYI, {complete} is also known as a covering axiom.)
Beware that if you do not specify {complete}, you're creating a conflict with the isAbstract meta-property. The reason there's a conflict is that in UML, the default is {incomplete}, which means that you are allowed to create an instance of the super-class without it also being an instance of one of the sub-classes. That conflicts with isAbstract.