I would like to add a transitive property islocatedIn into my ontology. My goal is to infer that:
City isLocatedIn Contient using City isLocatedIn Country, Country isLocatedIn Continent.
I have seen examples of transitive properties with a single domain and range, however I have not successfully modelled a transitive property with a domain and range spanning multiple classes.
How can I represent this in Protégé to obtain the aforementioned inference?
Asia, China and other concrete examples of Contient / Country / City should be individuals, not classes.
You can add class Place, for example (subclass of the main owl:Thing class and put you other classes to be subclasses of it too).Then just make your property to have Range only class Place.
Related
i am learning UML and I need some clarity about class diagrams.
for example I have the class
person with firstname, surname, date of birth as attributes.
what are or is the object? i do understand the class (that is person including the attributes), i do understand the attributes. but they are also talking about objects in my book, what would that be?
thank you in advance.
Where to start? Not that easy. Trying to find the definition of Class in UML 2.5 PDF is like looking for something in the remains of the Twin towers after 9/11 :-( So I took the UML metamodel published by OMG as XMI and imported that into EA. And there were are:
Class
You find the element like this:
and it's comment reads
A Class classifies a set of objects and specifies the features that characterize the structure and behavior of those objects. A Class may have an internal structure and Ports.
So, as it looks, a Class is derived from objects. Pretty much what Carl Linnaeus did in the 18th century. We can leave that for the moment and start looking for those objects.
Object
Trying to look for an Object element in the metamodel revealed: nothing. Probably for good reason since it's going into metaphysics. And Carl from above wasn't the only guy thinking about classification of the world.
Side note: I created an instance of Class in EA and ended up with an element of the metatype Object. A relic from pre UML 2.0 times. I looked into UML 1.5 and actually found a definition of object on p. 3-64:
3.39 Object
3.39.1 Semantics
An object represents a particular instance of a class. It has identity and attribute values. A similar notation also represents a role within a collaboration because roles have instance-like characteristics.
This has settled for a long time and is still in the mindset of most people. The IT guys defined a couple of classes out of the blue (with some requirements in mind) and when you use them you have these objects. Quite the other way around our Carl was approaching things. And now 12 years after UML 1.5 we have UML 2.5 and no trace of Object!
So, per UML 2.5 an Object does not exist. But we have ObjectFlow and ObjectNodes. So there must be something. On p. 12 of UML 2.5 you find
6.3 On the Semantics of UML
6.3.1 Models and What They Model
Classifiers. A classifier describes a set of objects. An object is an individual with a state and relationships to other objects. The state of an object identifies the values for that object of properties of the classifier of the object. (In some cases, a classifier itself may also be considered an individual; for example, see the discussion of static structural features in sub clause 9.4.3.)
and a bit below
UML models do not contain objects, occurrences, or executions, because such individuals are part of the domain being modeled, not the content of the models themselves. UML does have modeling constructs for directly modeling individuals: instance specifications, occurrence specifications, and execution specifications for modeling objects, occurrences, and executions, respectively, within a particular context.
Honestly I was surprised to read that, since I still live in the past where we had object diagrams (UML tools like EA still allow to create them). And that's probably the cause of the confusion. An object is by far too complex (and it has been in discussion since the invention of philosophy) to end up as UML element. Instead, UML allows to bring light to certain aspects of an object by using e.g. SDs to see details of behavior.
Summary
It's a bit of the hen and egg problem. Mapping between real world (the "Objects") and what has been modeled (the "Class") is tough. And it depends on your goals. Are you trying to get your head around somehing that already exists and sketch its behavior or is it that you have invented something new where you want to see how it interacts?
In any case, your question, so simple it is, turns out to be an excellent one!
I like qwerty_so's well documented and comprehensive answer. May I suggest an intuitive alternative?
A class describes features of the objects that belong to the class. For example, the class Person defines firstname, surname, dateOfBirth as properties. It also defines the type of these properties.
Object of the class Person, say John:Person or Jane:Person have specific values for each of the properties. The object John would have firstname="John", lastname="Doe", dateOfBirth=1961-10-01, whereas the object Jane would have firstname="Jane", lastname="Smith",dateOfBirth=1965-02-20.
The same difference can be experimented with in popular programming languages. Example:
// definition of a class, i.e. the general rules
class Person {
private String firstname;
private String lastname;
...
public Person (String first, String last, ...) { ... }
public void doSomething() { ... }
}
// definition of objects, that abide by the classe's rules:
Person Jane = new Person("Jane", "Smith", ...);
Person P2 = new Person("John", "Doe", ...);
// the objects need to have their properties set. But the behaviors of the class can be used without redefining them
Jane.doSomething();
I'm making a class diagram in UML, and I can't find information about this topic.
Can I have a class in several associations-classes?
here's an example:
Message should be an association class between user and group, but also between user and channel.
Is this allowed or is there any other way to do this?
thank you!
What is an association class?
When looking at the graphical notation of an association class, we could be mislead to think that an association-class is simply a class that is attached to an association.
But the association class is in reality an association AND AT THE SAME TIME a class:
UML 2.5.1 / Section 11.5.3.2: An AssociationClass is a declaration of an Association that has a set of Features of its own. An AssociationClass is both an Association and a Class, and preserves the static and dynamic semantics of both.
So in the modelling semantic, beyond the notation, you cannot separate the association class from the corresponding association. If you're not convinced yet, here the next sentence in the specifications:
An AssociationClass describes a set of objects that each share the same specifications of Features, Constraints, and semantics entailed by the AssociationClass as a kind of Class, and correspond to a unique link instantiating the AssociationClass as a kind of Association.
(links are instances of an association and correspond to tuples with "one value for each memberEnd of the Association")
What are the consequence of the association-class duality?
The consequence is that the same association-class cannot exist in multiple flavors that would each associate different sets of classes.
While nothing in the notation prevents you from adding a doted line to seemngly "attach" the same class to two different associations as Bruno explains, this notation would not correspond to a valid UML semantic.
Alternatives
Your question underlines an interesting design issue. And fortunately, there are plenty of ways to solve it. For example:
User class is associated to an abstract Destination class. Message would be the association-class. Destination would be specialized into Group and Chanel that would both inherit the association (no need to duplicate the association graphically). (Edit: as underlined by Axel Scheithauer in the comments, the association and the association class being one and the same, they must have the same name)
Forget about the association class. Make Message a normal class, associated with User. Associate it also with Group and Chanel. If necessary, add an {xor} constraint between these two associations if they are mutually exclusive.
The fact that you currently have a many-to-many association only with Group and not with Channel, suggest that there are some significant differences and would speak in favor of (2) rather than (1).
Not related: Something weird in your current model?
Regardless of the association-classtopic, you current model raises some questions regarding the many-to-many association with Group:
do you meant that several users can send a same message to several groups?
or do you mean that a user can send messages to a group and the group is made of several users?
In the latter case, you should go for 2 distinct associations: one for the sending association, and one for the group membership association (see the red association in the diagrams above).
This is a very interesting question.
In formal/2017-12-05 there is nothing in Figure 11.25 Associations page 199 nor in § 11.5.3.2 Association Classes starting page 200 nor in § 11.8.2 AssociationClass [Class] starting page 220 saying a class cannot be used for several associations-classes.
So for me it is allowed to have
but warning, the name of the class and the name of the association must be the same, from formal/2017-12-05 § 11.5.3.2 Association Classes page 200 :
Both Association and Class are Classifiers and hence have a set of common properties, like being able to have Features,
having a name, etc. These properties are multiply inherited from the same construct (Classifier), and are not duplicated.
Therefore, an AssociationClass has only one name, and has the set of Features that are defined for Classes and
Associations.
Then the class cannot be named Message and the associations sends if you want to make association-class.
Note class and an association are NamedElement (§ 7.8.9 NamedElement [Abstract Class] from page 47), a given name can be used for several NamedElement but to co-exist in the same Namespace two NamedElements must be distinguishable. From formal/2017-12-05 § 7.8.9.7 Operations page 49 :
isDistinguishableFrom(n : NamedElement, ns : Namespace) : Boolean
The query isDistinguishableFrom() determines whether two NamedElements may logically co-exist within a
Namespace. By default, two named elements are distinguishable if (a) they have types neither of which is a
kind of the other or (b) they have different names.
Then the two associations Message must be in different namespaces because they have the same name.
If you want Message to be an instance of a UML Association Class that connects User to Group and Channel, you can connect one end property of the Message association to an instance of a UML Class that is the union of Group and Channel.
To construct a union class, make it the general end of two instances of UML Generalization and make it abstract. The specific end of one generalization would be Group, and the other would be Channel. For extra clarity, put the generalizations into an instance of a UML Generalization Set that is {complete}.
Through searching I found that in UML, aggregation(assuming that it's used properly) can be used to represent attributes in a class.
For example,
(Assume column can stand alone)
Then, using such example, if I want to replace the attribute: Column[] with map to represent the column's name, would it be correct to use an association class just like below? (In case, I'm not willing to put the column name in Column class as an attribute)
Association classes are used with simple associations. They have m-1-1-n multiplicity. The shared aggregation (as you used) has no defined semantics (and I recommend to simply not use it unless you have a domain specific and documented use for it). It's simply better to put the intended multiplicity on either side of an association.
An association class connects two classes, adding attributes and/or operations. Your example is "unconventional" since Table/Column have a simple relation which would not need an association class. A general example is the Student/Lecture relation where you can put an association class in between to record exam results, times etc.
Yes, I think that is a valid way of modelling the fact that you have some sort of key string that can be used to identify a Column of this Table.
Using a Map is one if the many possible implementations, so it's not a real equal to.
The advantage of modelling using the Association Class is that your model remains at the more abstract functional level and leaves out implementation details.
BTW. I would use a composition instead of an aggregation for the association between Table and Column, as there is an obvious strong ownership relation and life-cycle dependency between the two.
If you want to replace the attribute Column[] with map to represent the column's name and you are not willing to put the column name in Column class as an attribute and assuming that you want to follow UML specification precisely then you'll produce the model shown below:
Map<Key, Value> is usually understood as an associative container that contains key-value pairs Map.Entry<Key, Value> with unique keys. The container is modeled by the directional aggregation from Map<Key, Value> to Map.Entry<Key, Value>.
Map<Key, Value> and Map.Entry<Key, Value> are templates. Clause 7.3.3.1 of UML specification says that:
A template cannot be used in the same manner as a non-template Element of the same kind. The template Element can only be used to generate bound Elements or as part of the specification of another template.
According to clause 7.3.3.3:
A TemplateBinding is a relationship between a TemplateableElement and a template that specifies the substitutions of actual ParameterableElements for the formal TemplateParameters of the template.
Thus we have two bound elements that have TemplateBinding (marked by <> keyword) relationships with their templates:
ColumnNames which essentially is the name for Map<String, Column>
ColumnName which essentially is the name for Map.Entry<String, Column
According to clause 11.5.1 of the UML specification:
An Association classifies a set of tuples representing links between typed instances. An AssociationClass is both an Association and a Class.
ColumnName is AssociationClass representing the link between instances of String and Column classes. We use notation from clause 11.5.5, figure 11.35 to express that.
Finally, the directional composition association between Table and ColumnNames classes tells us that each instance of Table owns an instance of ColumnNames, i.e. set of column names.
Note that while ColumnNames and ColumName classes are usually hidden from the end-user by an implementation, they nevertheless exist.
I used BoUML to draw the diagram.
Let's assume I have 2 classes with association relation.
What is the difference between adding attributes to one of the classes and adding an Association Class with attributes?
I understand that association class describes the association relation, but cannot I use simple class attributes instead?
What are the added values of Association Class?
Association and attributes are actually different renderings of the same thing. The difference is more a bit of esoteric nature. An association is visually more exposed than an attribute. So you would use the attribute if it has a more local importance rather than a more system wide in case of an association.
What you should not do is to use both. When using an association and you need to name it then use a role along with the association and do not repeat it as attribute.
An association class (AC) is actually a combination of a class and an association (in UML it inherits from both). This way the pure relation between two classes can have methods and attributes itself. An association class is used if you want to relate two classes with M-N relation. E.g. the AC between Student and Exam describes the results a student has achieved in exams. So you have a Class 1-M AC N-1 Class relation rather than having this information as array attributes inside either of the opposing classes.
As a side note (since you tagged it EA): EA offers a drop down in the roles which is fed from attributes of the class. You should not make use of that. This is some heritage and/or a misinterpretation of the definition. As said: its not wrong, but also not good style.
You say you already have two classes with an association between them. In that case, there is a huge difference between adding attributes to one of those two classes and changing the association into an association class with its own attributes. They are not at all similar.
Unnamed properties already exist at each end of the association and are typed by their adjacent class. Adding redundant attributes is unnecessary and would be incorrect.
An association class allows you to record additional facts about a link between instances of the other two classes, such as the point in time the link came into existence. Association classes are like associative entities in a database.
I think part of your question is also about when to use an association vs when to use attributes. The UML spec doesn't provide any guidance on this. However, common practice is to use an attribute only for types that have no identity, such as the number "5", the string "Hello", or the combination of "7" with an enumeration literal of "pounds". In UML, these types are called primitives and datatypes. If you want a property typed by one of those, use an attribute; otherwise, use an association with named association ends.
I have a confusion about UML in my class diagram.
A person has 2 address, the first is obligatory, the second is not.
How do I represent that?
An address should be better not modeled as a class that represents an object type, but as a complex datatype, which is represented as a class rectangle stereotyped with <<dataType>>. For modeling attributes having such a datatype, you wouldn't use any association in the class diagram, but simply use the name of your complex datatype Address as the range/datatype of your attributes primaryAddress and secondaryAddress.
You would usually show that with attributes and role names with multiplicity on associations:
See comments regarding the use of attributes/roles on associations.