I want to understand the difference between connecting classes together with a shared line or by having classes only "connect" through other classes. Is there a significant difference here? If classes share a line are you specifically trying to convey that information is being accessed from each of the other classes on the shared line?
For "Three Objects in a Row" I mean a layout that would appear as follows (sorry my diagram is:
For "Sharing Lines" I mean a layout that would appear as follows:
difference about access
In the first case instances of Flat and instance(s) of Tenant know each other, and independently of that instances of Tenant and instances of LeaseAgreement know each other. Instances of Flat do not have direct access to instances of LeaseAgreement and instances of LeaseAgreement do not have direct access to instances of Flat, they can only access the other instances if Tenant offers these accesses whatever the way (method or public attribute).
In the second case there is an association-class, instances of Flat and Tenant know each other more the corresponding instance of LeasingContract indicating how they are associated.
difference about knowledge
In the first case supposing the hidden multiplicity are not 1 a tenant having two rents is associated with two instances of Flat and two instances of LeaseAgreement but there is nothing in the given model allowing to link the right instance of LeaseAgreement with the right instance of Flat, that means the model as it is do not say for which flat a lease agreement was written.
In the second case there is no ambiguity, each couple of instances Flat and Tenant is associated with (in fact throw) the right instance of LeasingContract
The notation in your lower picture is called Association Class (see this wiki). Bascically it's a shortcut for a 1-* AC *-1 relation where AC is connecting two classes so you can add attributes and operations. In your example the AC is Leasing contract and it would add information about duration, payment, etc. And the two * were taken from the * left and right on the AC's association's far ends. So this would be an equivalent of your lower diagram:
Related
For example, imagine a diagram where there are 2 association ends such as incoming/outgoingRoads. Is it possible to store these roads together in the same arraylist by giving them the same name like "allRoads" that contains both incoming and outgoing?
Or is there other way to solve this?
naming both of them with same name in uml app brings no errors
Two association ends at the opposite side of the same class are not allowed to have the same role name. It would create a naming ambiguity for City.allRoad:
Two association ends at the opposiste side of different classes can have the same role name. There would be no ambiguity between City.allRoad and WorkOrder.allRoad
Two ends of the same association can have the same role name as well. There would be no ambiguity between City.direction and Road.direction:
In the same way, there is no problem of having two associations between the same classes but with different end names:
Your design could as well deal with only one association for both incoming and outgoing roads. At least three different design could be considered:
making the road graph bidirectional, i.e. if all incoming routes are at the same time outgoing roads (caution: this is a substantial change in the underlying model: it would for example not allow to represent one-way roads)
using an association class, that would tell for each associated road, if it's incoming or outgoing.
using a qualifier (which would probably be implemented as a map or a 2d array, as qwerty_so mentioned in the comments):
I made a concurrent system which has a critical section which involves read and write access to a TXT file.
First, an Auctioneer class creates a TXT file and writes the number 50 to it. The Auctioneer then allows the next node, one of three instances of the Bidder class, to open the file and change the current bid. The bidder class then allows the next node, another bidder to bid, then another bidder, and then that bidder allows the Auctioneer to look at the file.
I allowed the nodes to take turns using server sockets. Each node waits for access using the ServerSocket.accept() method, and allows the next node to enter its critical section by creating a Socket object with the socket that ne next nde is listening on.
Each of these nodes run independantly in seperate java environments and only communicate with server sockets.
Each node of the ring relies on the previous node because in order for that node to access the resource, the previous node needs to pass the current node the token. I'm unsure on how I would represent that kind of relationship in a UML compliant way.
It is of my understanding that class diagrams should not include several instances of the same class such as the example below with 3 bidders.
Is this the correct way to represent the relationship which I have described? If not, which way would be better/UML compliant?
Class diagrams, as the name suggest represent classes of objects and not individual objects, i.e. instances of these classes. Moreover, a class diagram is structural: it does not tell how objects interact or wait one for another, but how classes relate.
In tour case the class diagram would therefore represent one bidder class. To represent a concrete example with instances and how they relate, you could consider an object diagram. There you could very well represent different instances of the same class.
However, if you’re interested in the interactions between classes (e.g. the tokens they exchange), you’d better consider an interaction diagram such as the sequence diagram.
I have a hard time understanding the concept of association class as explained in UML 2.5 specification. The thing that confuses me the most is the following sentence taken from page 199:
NOTE. Even when all ends of the AssociationClass have isUnique=true, it is possible to have several instances associating the same set of instances of the end Classes.
As noted here: https://issues.omg.org/issues/UMLR-757 this single sentence seems to undermine the usefulness of the concept. At the same time, it makes pretty much every text explaining the concept written before 2.5 version of the UML spec obsolete – see for example the discussion here: UML association class - clarifying
But how can this actually work conceptually? Assuming all ends of the association class have isUnique=true, how can one have more than one instance of association class associating the same set of instances of the end classes, when isUnique property of member ends clearly forbids existence of such links?
I’ve always thought that an association class is just a regular association with extra attributes and/or operations. That interpretation seems to invalid now. So what exactly is association class? How can it have uniqueness independent from that of association member ends? There seem to be some unspoken multiplicity lurking somewhere (uniqueness is irrelevant property without maximum multiplicity higher than 1), but I can't figure out where.
In very short
Indeed, this is not super-clear and would deserve a better explanation. To make it short: it’s just a consequence of the lack of integration in the dual semantics defined for the association class.
Detailed explanation
What is uniqueness for an association
According to UML 2.5.1 section 11.5.3.1, page 197:
When one or more ends of the Association have isUnique=false, it is possible to have several links associating the same set of instances.
We can deduct using logical contraposition that:
If it is not possible to have several links associating the same set of instances, all ends of the association have isUnique=true.
So we'd expect this to apply to an assocation class as well, since the association class is also an association.
Association classes are two distinct things at the same time
According to UML 2.5.1 section 11.5.3.2:
An AssociationClass is both an Association and a Class, and preserves the static and dynamic semantics of both.
So, an association class is not just "an association with extra attributes". If it were that simple, the association class could perfectly be a generalization of an association: the specialized association would just inherit the extra attributes. But this is explicitly prohibited page 199:
An AssociationClass cannot be a generalization of an Association or a
Class.
because any specialization into a class would loose the association semantics, and any specialization into an association would loose the class semantics.
And this duality, is the cause of our issue.
Impact of this duality on instances
According to UML section 11.5.3.2, page 199 (formatting from me):
An instance of an AssociationClass has the characteristics both of a link representing an instantiation of the AssociationClass as a kind of Association, AND of an object representing an instantiation of the AssociationClass as a kind of Class.
If isUnique=true for all association ends, the instances of the association are guaranteed to be unique. Remind however that the association is only about tuples made out of the association ends:
An Association declares that there can be links between instances whose types conform to or implement the associated types. A link is a tuple with one value for each memberEnd of the Association, where each value is an instance whose type conforms to or implements the type at the end.
However, nothing in the specs requires that the class instantiation (object) representing the association instantiation needs to be unique.
Imagine for example, that we have an association class between class A and class B, and a and b are instances of these classes. Imagine that the association ends have isUnique=true. This means that there can be only one tuple (a,b) since the association is guaranteed to be unique.
Let P be a property of the association class, and let (a,b,p1) and (a,b,p2) be two instances of the class in the association-class. The class knows no association-ends: from the point of view of the class, there is no unicity requirement. And from the point of view of the association, we have only one tuple (a,b) , so it's ok as well.
The NOTE just explains that this (unfortunate and ambiguous) situation is possible.
Are there contradictions or inconsistencies?
Formally, there is no contradiction. This is the result of the way the association class is defined: a class and an association at the same time, without further defining the relationship between the respective instances.
But this creates some issues in regard of the semantics of associations having non-unique ends:
When one or more ends of the Association have isUnique=false, it is possible to have several links associating the same set of instances. In such a case, links carry an additional identifier apart from their end values.
More precisely, this makes the the association-class with unique ends useless, since the same result can be achieved with non-unique ends:
for a simple association with non-unique ends, you can have duplicates, i.e. several links associating the same instances of the association ends that are distinguished with an additional identifier.
for association classes with unique ends, according to the note you can have duplicates, i.e. several objects (class instances) corresponding to a link made of unique association ends (association instances).
for an association-class with non-unique ends, you could have duplicates, i.e. several object instances correspond to the same set of member ends. It makes no difference if you interpret this as several links associating the same instances of the association ends, each associated with a single object, or, if you interpret this as one link associating a unique set of instances of the association end, that would be each be associated to mutliple object instances.
IMHO, this is unfortunate:
it does not match our mental model in which an association class with all association ends having isUnique=true should have a unique object instance of the class for a unique combination association ends. This clearly goes against the principle of least astonishment: I started with deny and it took me a while to accept this, since it was so terribly different from the traditional ways to implement association classes.
two different models, one with unique association ends, and one without could in fact express the same situation.
A simple solution to this issue would be to require a unique class instance (object corresponding to the association class) to correspond to a link that uniquely associates association ends. In that way, unique association ends would imply unique association object, without requiring other changes to the UML specs.
I have this basic class diagram:
and was wondering whether this object diagram is allowed:
The class diagram is given and I was wondering whether it is possible to create an object diagram where two customers (maybe wife and husband) are sharing the same bank account with this structure. But because a composition is used, the bank account would get deleted if one of the owners gets deleted right? So this class diagram is not really suitable for shared accounts, right?
This scenario for the objects in the second diagram is indeed not valid. The reason is that composition implies an exclusive ownership.
For an account to be shared by several customers you’d have to change the class diagram, for example:
use aggregation instead of composition (white diamond). Although its semantics are not well defined in the UML specification, it allows in any case for shared ownership.
use a simple association (without diamond). You could express the fact that an account has several customers with an explicit multiplicity.
use a composite client: the client could either be a single person, or a group of several clients. This construct is more complex.
I am trying to create an UML diagram for a graph in MongoDB.
I have tried
but I am afraid it is wrong, since both source and target in Edge should point to Node, so I guess it should have two arrows?
Also, I don't know what to write on the question marks.
A graph can have multiple nodes and edges, so the relationship from Node to Graph and Edge to Graph is one-to-many (i.e. there can only be one Graph associated to one Node/Edge). Also there can only be one Node associated with one source and one Node associated with one target.
Is it even correct to draw these UML Diagrams for MongoDB collections since they are non-relational databases?
I would start modeling it this way:
So a graph consists of a number of nodes which are connected by edges. Edges are always between two (not necessarily different) nodes. In this way you can not individually model graphs that have different relations. If that is needed, you would need a different model here (probably you'd add an association between Graph and Edge). Alas, this shows how UML is used: starting a discussion and talk about the problem domain.
Now, how this is finally mapped to a database is completely irrelevant at this stage. You can map this to relational and non-relational DBs later.
Regarding the questions from your comment:
The position of associations in a class diagram is irrelevant. They just need to end in the right elements.
The +source and +target are role names. They are identical to properties of Edge with names source and target and type Node. The + is the scope public (- would be private; there are 2 more)
The 1..* means that the Graph has many relations to Node. It does not tell how this is realized. Could be an array later or other means of expressing multiplicity.
Yes. The position of role and multiplicity is important. This is a drawback since UML tools place them automatically and they can eventually be placed badly with many connectors/narrow element spaces.