I have a question about my UML diagram. I have made a system consisting of a "User" parent class and the two child classes inherit from the "User". Now my question is how to show the multiplicity notation between them, just like the multiplicity notation is shown between "Booking" and "client", where more clients can only have one booking each and the notation would be many to one.
The question is:
The user in our system can only be a practitioner or a client, not both at the same time -->, therefore, the notation would be 1 to 1
There are more users and the different users could be either a practitioner or a client --> therefore the notation would be 1..n to 1..n
What is the right way to write it? Is it wrong to write multiplicity notation when a class inherits? Please help I have spend like 2 hours on figuring it out.
You don't. There are no multiplicities on a Generalization in UML.
The fact that your User is either a Cient or Practitioner can be expressed by setting your User abstract. The notation for abstract classes is to set the name in italic. This way you cannot instantiate User instance directly, but you have to use one of the concrete subclasses.
The second phrase doesn't really constrain anything, so you don't have to mention it at all.
Remark: the guillemets « and » are reserved in UML to denote stereotypes and keywords. As it is right now your User class is really an unnamed class with stereotype «User»
Related
In an UML class diagram:
a) Do you have to state attributes that are aggregated? Or is it enough with the arrows indicating aggregation?
b) Do I have to add "id" as an attribute or is it a given?
Thanks.
You are using a shared aggregation in the picture. That does not have any defined semantics as per UML 2.5 (see p. 110). If you need a composite aggregation the diamond must be filled. In that case the aggregated object will be deleted along with the aggregating one (the latter must assure that constraint). In your model it makes no sense. No employee aggregates a department. Even vice versa I would have doubts or at least reason for discussion.
An id is only needed if it has a business purpose (e.g. an article number). If you transform your model to a database you introduce an artificial id for technical reasons. But on an abstract business level they are not modeled.
Your models only differ in the use of attributes for associated classes. The B variant is preferred. But you need to place the attributes as role names towards the associated classes (as -department and -branch). What you have placed in the middle of the connectors is rather the association name. Badly chosen with the + in front. Naming associations is rarely needed. So get rid of that. Role names shall be placed near the class that takes the role. Also it's a good idea to use the dot-notation to show that the roles represent owned properties. Just place a small black dot near the left hand side of both (near where the role names should go).
As for the dot-notation UML 2.5 states on p. 18:
Dot notation is used to denote association end ownership, where the dot shows that the Class at the other end of the line owns the Property whose type is the Class touched by the dot. See 11.5.4 for details of Association notation and 11.5.5 for examples.
Also as JimL. commented the A-version uses associations plus attributes which introduces redundancy. This is not illegal but likely not intended and at least leads to confusion.
While I googled to understand the Unary associations, I got the following two explanations:
the first is:
A unary relationship is when both participants in the relationship are
the same entity. For Example: Subjects may be prerequisites for other
subjects, or one employee manages many Employees.
and the second is:
Class B knows about ClassA.
Class A does not know about ClassB.
Now lets look at the following example:
You can see the Person and Address relationship below. We call this
relationship as has-a relationship since person has a address. So
Person knows the address but address does not know anything about
person
Am I misunderstanding something?
Common language
The arity of an association is about how many classes are associated. This is an ambiguous concept since some understand different classes, whereas others understand instances.
When applied to unary, the first interpretation would mean reflexive association (or self-association, i.e. a class associated with iteself), whereas the second would mean a class associated with nothing (not very useful: any class could be associated with nothing else).
UML perspective
Fortunately, the UML specifications are much more precise than the common language:
An Association specifies a semantic relationship that can occur between typed instances. It has at least two memberEnds represented by Properties, each of which has the type of the end. More than one end of the Association may have the same type.
So in UML there is no "unary association". It's binary, ternary, or n-ary (terms used in the specs). There is no special term in UML for a binary association with the same class at both ends. But reflexive or self-association are terms which are more popular than unary.
E/R modeling
The term "unary" is popular in the context of entity-relationship modeling, to describe a relation in a relational database. Relations correspond more or less to an association in UML, and entities to classes, but there are some subtle semantic differences. E/R has its foundation in the set theory. And if a relation is between the same entities, it means in fact that only one set is involved. This is probably why unary is more popular in this context.
Merriam-webster defines Unary as
having, consisting of, or acting on a single element, item, or
component
So the first explanation is correct one since this type of association acts on a single class. The term Unary however is not used in UML and might be confusing.
UML uses the term binary to indicate that an association has two ends, and ternary or n-ary to indicate an association has multiple ends.
The Unary association you are talking about is actually a binary association to itself, also known as reflexive association.
Not to be confused with a Unidirectional association, which is an association that is only navigable (has an arrow) to one side.
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}.
What I would like to ask is that if one class has a variable of array, should I include it as attribute along with the association or only the association?
So, for example, if I want to draw a simple diagram about association between professor and lecture, which side would be correct (Upper one or the lower one)?
- Lecture may have more than one instructor
You would use the dot notation with role names like this:
It means that Professor has * lectures as owned property and vice versa Lecture has 1..* teachers.
The dot and role name are located "on the opposite site" of the owning class.
hi every body i'm trying to understand UML but there are some questions about it
In UML what is the significance of tagging a class with the stereotype <<abstract>>?
and how to express this constraint as an invariant,
A stereotype "abstract" does not exist - an abstract class should be depicted using italic font. Abstract means that a class cannot be instantiated. It needs a subclass to do so. So as a pseudo-code constraint this would mean
for all instances i of MyAbstractClass holds: i.actualClass != MyAbstractClass
or in ocl for MyAbstractClass holds
self.allInstances()->forAll(i: MyAbstractClass | i.classifier <> self)
As the word 'abstract' was not displayed in your first question version, I expanded on stereotypes in general:
First of all: When learning UML, stereotypes should not be the first things you look into. They are rather complex.
Stereotypes or keywords (both denoted with <<MyStereotype>>) do not have a general meaning. It is defined by the specific stereotype. Commonly you cannot express a stereotype as an invariant instead.
But some other aspects of UML can be shown the same way: A class from the UML Metalevel is marked with <<metaclass>> even though it does not have a stereotype or even is of different actual type. The Stereotypes themselves are shown with a <<stereotype>> marker (even if they are instances of a special class).
An example for a custom stereotype could be "Service". You could mark classes with it which represent a Service. There could be a constraint which tells you that a "Service" must implement a special Interface. In this case you could express this constraint as a (boring) invariant. But probably it is even just a marker. In the latter case you can use a keyword as replacement.
I realize this thread is a couple of years old, but I came to it when it was referenced by someone else, as supporting the assertion that the «abstract» stereotype isn't supported by the UML spec. That assertion isn't quite accurate, and I'd like to explain why. I'll start by clarifying what abstract classes are.
Abstract classes are definitions of classes that don't include complete implementation. Therefore, abstract classes can't be directly instantiated; they have to be specialized (inherited). Abstract classes are notated by italicizing the class name and the methods that are abstract, and additionally by optionally adding an {abstract} property to the class name and/or to the operations (methods, we usually say, but methods are actually the "method" by which the operation is implemented) that are abstract.
Interfaces are actually a specific type of abstract class: a class with zero implementation. Their notation is different from other types of abstract classes (don't italicize, use the «interface» keyword, and notate all the specialization arrows with dotted lines). So, as Christian says here, there is standard notation for abstract classes--at least, there is in class diagrams.
Now, while it is true, as Christian also says, that the «abstract» stereotype doesn't exist, it is also true that you can create it if you want to, and that doing so is supported by the UML spec. It's unlikely that you'll have a reason to (at least in class diagrams), but you still can.
A stereotype is an "extensibility mechanism" for UML (there are three: stereotypes, tagged values, and constraints). It allows you to more specifically define some sort of element. Stereotypes are applied to classes (metaclasses actually, metaclasses are classes whose instances are also classes). A number of stereotypes are pre-defined "Standard Stereotypes" (in UML 1.4 they were called "Standard Elements"). Examples of these are «metaclass» (again, a class whose instances are also classes) and «file» (a physical file in the context of the system developed).
Stereotypes are a type of keyword. The spec (Superstructure 2.0, Annex B, p. 663) has this to say about keywords:
UML keywords are reserved words that are an integral part of the UML
notation and normally appear as text annotations attached to a UML
graphic element or as part of a text line in a UML diagram. These
words...cannot be used to name user-defined model elements where such naming would result in ambiguous interpretation of
the model. For example, the keyword “trace” is a system-defined
stereotype of Abstraction (see Annex C, “Standard Stereotypes”) and,
therefore, cannot be used to define any user-defined stereotype.
In UML, keywords are used for four different purposes:
To distinguish a particular UML concept (metaclass) from others sharing the same general graphical form...
To distinguish a particular kind of relationship between UML concepts (meta-association) from other relationships sharing the same general graphical form...
To specify the value of some modifier attached to a UML concept (meta-attribute value)...
To indicate a Standard Stereotype (see Annex C, “Standard Stereotypes”)...
Keywords are always enclosed in guillemets («keyword»), which serve as visual cues to more readily distinguish when a keyword is being used...In addition to identifying keywords, guillemets are also used to distinguish the usage of stereotypes defined in user profiles. This means that:
Not all words appearing between guillemets are necessarily keywords (i.e., reserved words), and
words appearing in guillemets do not necessarily represent stereotypes.
In other words, you can create any stereotype that you want, so long as it isn't a keyword. Since "abstract" is not a keyword, it follows that you can create an «abstract» stereotype.
In order to do so, however, you would have to go to some trouble, more trouble in UML 2.0 and above than in UML 1.4. UML 1.4 simply stated that a stereotype was an extension mechanism for the UML spec. One could simply define the stereotype, apply it to whichever part of the UML metamodel one wanted, and document the change. UML 2.0 wanted to formalize the relationship of a stereotype to a UML metaclass (any item on a UML diagram is a metaclass, and part of the UML metamodel). So, they came up with Profiles. This sample diagram shows how profiles work:
Now, that black arrow may look a bit strange, since you don't see it in any context but this one. UML 2.0 introduced the concept of an Extension, which it defines as "used to indicate that the properties of a metaclass are extended through a stereotype." This black arrow indicates an extension.
I'll quote Tom Pender (The UML Bible, Wiley Publishing, 2004) for an explanation of this diagram, since he does a better job than the spec (and I certainly can't improve on it):
It shows that a Component is extended by a Bean stereotype, which is required. The Bean stereotype is an abstract type, with two subtypes - Entity and Session. Each instance of Component, therefore, must be extended by an instance of either the Entity stereotype or the Session stereotype. Remember that a stereotype is a kind of class that can have properties - in this case, a Session stereotype has an attribute named state. This corresponds to a tagged definition whose value specifies the state of the Session. The tagged value is an enumeration, StateKind, which has either a stateless or stateful value.
The Component has a constraint on it, displayed in the note attached to the Component symbol, which states that a Component cannot be generalized or
specialized.
The diagram also shows that an Interface metaclass is extended by the Remote and Home stereotypes. The EJB package has a constraint, displayed in the note that sits in the package, that states a Bean must realize exactly one Home interface.
So, you can indeed use an «abstract» stereotype if you have reason to go to the trouble of creating it. The main reason that anyone might want to is to represent an abstract class in some place other than a class diagram.