My group and I are making a program, where we have a tree structure. In this tree structure we have made it such that a category can contain it self. The program is based on your expenses, so an example could be:
You have bought 4 milk. The 4 items of milk are placed in the category "Milk". Each entry of milk has the price (along with other individual information) in another class which category aggregates.
The trick is that we want the category class to be able to contain it self, so:
The category "milk" is part of the category "Dairy Products", which in terms are part of the category "Groceries".
The reason we want it to be like that, is so we can move batches of products at the time. So if you want to move Milk to a category called "Morning Stuff" you wouldn't have to move every single one, but instead just the entire category.
The picture is how our current category class is modelled, but we were told we couldn't do it without much further explanation. Does UML allow this? If not, how can we model it with UML?
Yes, UML allows associations from a class to itself. Likewise aggregations and even compositions are allowed this way.
The image you posted shows an aggregation while from your description I would have chosen a composition (filled diamond): a category has one or no parent; a category is somewhat defined by its children; if a category gets deleted all children are deleted as well.
A longer comparison between aggregation and composition can be found here.
Yes it is allowed, but in most cases it is better to aggregate an abstraction (abstract class or interface) in order to preserve Polymorphism rather than the item its self; see the Composite Pattern for an example.
This is known as the Interface Segregation Principle and is one of the five SOLID principles
Related
I'm doing an assignment on class diagram and the following shows the association between classes Order and Menu Item. Should the link be aggregation (weak) or composition (strong)?
I'm confused because I've seen example showing aggregation. I felt it should be composition as an Order must have at least 1 Menu Item added. Am I wrong?
Should the link be aggregation (weak) or composition (strong)?
It can be both. The main difference is:
In case it's a composition:
MenuItem objects are instantiated at the instantiation time of the Order object.
The MenuItem objects are destructed as soon as the Order object is destructed.
C++ example:
class Order {
MenuItem menus[NUMBER_OF_MENUS];
};
In case it's a aggregation:
The lifetime of the MenuItem objects is independent of the Order object lifetime.
C++ example:
class Order {
MenuItem* menus[NUMBER_OF_MENUS];
};
So it's a design decision. And might also depend on the implementation language. In Java, for example, there is no distinction between both, all object variables are references.
A lot is dependent on context. Let's use an example that should clarify the difference for you.
Suppose you are assembling a Car object in a car factory. The Car object has two Axle objects, four Wheel objects, a Motor object, and so on. All of those objects only have meaning within the context of the entire car (once you put them in, they stay there). That's composition.
Now, suppose you have a Car object in a junkyard. The Car object has the same stuff, but you can pull wheels or axles or the motor out of it and sell them separately. In that case, each part has a lifetime separate from that of the car. That's aggregation.
I'm a bit confused regarding Generalization, Aggregation and abstract classes in UML.
By Generalization, I can understand that it's a "is a"-relationship. A student is a Person - and a teacher is a Person. So Person would be the superclass, whereas student and teacher are both subclasses.
By Aggregation, this is what I understand: It's a "softer" relation compared to composition. An example could be: You can have a hand with no fingers (aggregation) but you can't have fingers without a hand (composition).
And then I am completely lost on abstract classes. What are the characteristics of abstract classes? I'd like an example on this if possible.
But am I on the right track here? This is how I understand these terms.
You understand Generalization.
Associations may be Aggregations or Compositions (or neither). This is a good example that Tom Pender used to use. Suppose you have a Car class. That Car class "has" a steering wheel, seats, two axles, four wheels, and so on. If you're creating that Car in a manufacturer context, the relationship between all of those would be Composition: the lifetime of all the car's parts (at your manufacturer) is tied to the lifetime of the car. From the standpoint of the manufacturer, the lifetime of the car and all its parts ends when you deliver it to a dealer.
Now, let's suppose you're the owner of a junkyard. In this case, a car still "has" all those parts, but they have a lifetime of their own: you can sell parts off of the car, and even make them part of some other car if you need to. The relationship between the car and those parts is Aggregation, because the lifetime of the parts isn't tied to the lifetime of the car itself.
So, you can see that the same car could actually be modeled in two different ways depending on context.
As for abstract classes: an abstract class is simply a class that defines methods and/or properties while requiring that they can only be implemented in subclasses. It's easiest to explain why with interfaces. Interfaces are abstract classes, with the added proviso that NONE of the methods or properties can be implemented directly in the class (you might say it's a definition of how to define a subclass). Here's where they come in useful.
Suppose I want to define an Animal class. What do animals do? Well, they move. They bite. (They do other things too, of course, but let's stick to Move and Bite.) If I create an Animal interface, I'm saying "here's what an animal does. If you want to be an animal, you have to also do these things. However, I'm not going to tell you how to do them." So, I create an iAnimal interface, with two methods, Move and Bite. As an interface, I don't provide any sort of implementation, just empty procedures.
Now, suppose I have two animals, a Flea and a TRex. Clearly, Fleas and TRexes don't have anything in common in the way that they move or the way that they bite, but they both do both. I'll have Flea and TRex inherit or "implement" the interface, providing implementations of Move and Bite appropriate for the type of animal.
The advantage of this is that clients of my flea and trex don't have to know which one they are dealing with. They can create an iAnimal, inject an instance of Flea or TRex as appropriate, and safely call iAnimal's Move and/or Bite methods without having to worry about whether they're supported or not. (This is what we mean by "polymorphism").
So, interface implementation is a form of Generalization (more correctly Specialization, going the other way), as you have probably already surmised.
From here, an "abstract class" is simply any class with any method or attribute defined that has to be inherited to be implemented. Therefore, as I have said, interfaces are abstract classes. However, in general usage, an abstract class is taken to mean one that is not also an interface, i. e. one that has some concrete methods or attributes. Most programming languages adhere to this definition.
I have one object, call it type A which has four data members of another object type, call it B. How do I show this in a UML class diagram so that its clear there are four B objects type in every A object?
Is the only solution to put "4" next to the arrow head pointing to class B?
It depends on what you want to achive, in sense of how you need to distinguish between those objects in context of their association/link, that is - what kind of role they play:
if there are all equal, no special differences in their role in context of A, them a multiplicity 4..4 will do the job, naming the association end properly (for example my_Bs)
If these object play different role in connection with A, then you can use separate associations with lower multiplicities each one, 2, 3 or even 4 pieces (for example, if B is a Wheel and A is Car, then you can put 2 associations with multiplicities 2..2 each, and call then "front" and "rear", or even 4 associations "front_left", "front_right"...)
Here is how the both cases look like. On the second one I showd different possible options (with max. 5 elements of B), just to give you an idea.
It's probably clear by now, but the fundamental concept here is the role of the association end.
Aleks answer is the best. However you can also represent the multiplicity in one box like this :
You cal also use composite structure diagram. See example below:
From my point of view, myBs defined as an attribute of type B on class A has a different meaning of myBs defined as a association's role between A and B (which is also different as defining it as a composition/aggregation).
If it is an attribute, then it's not a role. In that case, there is only a simple dependency relation between A and B, which must appear in the diagram.
I think that problem comes from unconsciously think from a "Relationnal Data (BMS)" and/or a "Object Oriented Programming" point of view, but UML is not intended for that.
:)
An association defines a semantic relationship between classifiers. The instances of an association are a set of tuples relating instances of the classifiers. Eachtuple value may appear at most once. The Association represents a set of connections among instances of the Classifiers. An instance of an Association is a Link, which is atuple of Instances drawn from the corresponding Classifiers
I wonder if there is someone helps me understand every word of the association definition especially the highlighted ones?because I read about it from different resources but all of them say the same words but I would like a more elaborated definition
semantic relationship
This means there's a structural relationship between the things being associated that arises from the problem space. For example: the association Person owns Dog. In a dog licensing application, this relationship is the central concept; the application exists to manage the links between people and dogs. It's a 'semantic' relationship because it has meaning which originates from the problem space.
set of tuples relating instances of the classifiers
A tuple is 'an ordered set of elements' (wikipedia). An example of the Dog-Ownership association could be ("Fido", "Fred") where "Fido" represents a Dog and "Fred" a Person. An association can be represented as a set of tuples in that there is one tuple for each combination of Dog & Person for which the relation holds; e.g.
[("Fido", "Fred"), ("Angel", "Chuck Norris"), ("Boatswain", "Lord Byron")]
Note there are no tuples for pairs where the relationship doesn't hold; e.g. ("Fido", "Lord Byron").
each tuple value may appear at most once
It's not possible for the set to contain duplicates as this would just be saying the same thing twice. So there's no point adding ("Fido", "Fred") again to the list above; we already know Fred owns Fido.
The Association represents a set of connections among instances of the Classifiers
This is just another way to think about the relationship. For each tuple in the set, you can think of a link - or connection - between the related objects.
An instance of an Association is a Link, which is a tuple of Instances
See above. Each tuple represents one linked pair of objects. Links are to Associations as Objects are to Classes. Classes have many objects; Associations have many Links.
Fundamentally associations exist to show where things are systematically linked to other things. Tuples and sets are a way to think about and/or represent those linked things. (In fact I'd quibble somewhat with the definition in your OP: the links in an association can be represented as as a set of tuples: but that's not what they are, it's how they're modelled. The same information could equally be modelled by a Graph, where each object was represented by a vertex (node) and each association an edge.
hth.
EDIT:
Responding to your questions. Looks like you understand it pretty well; some observations.
First, here's how I would model it:
Now to each of your points:
Name: is the name of Association relationship(optional,you can give it a name or not)
I prefer verb phrase based naming as it brings out the meaning of the relationship. My model can be read directly as:
Each Person owns many Dogs (where 'many' means 0 or more)
Each Dog is owned by exactly one Person
Doing so removes the need to name the association explicitly, although you can still do so if you want.
visibility(I am not care about it,at least for now, I didn't realize its importance until now).
I would agree. Personally, I never annotate models with visibility.
Name:(here is the name of MemberEnd ),so,I left its default name in the screenshot
See comment about association naming above. I prefer verb-based naming to role-based: 'owns' is much more explicit in describing the purpose of a relationship than naming the association end 'dog' or 'dogs'.
the owner of memberEnd [...]
Personally: I don't use this. There's a whole other discussion about this that tbh I don't believe has a material impact in most cases.
Navigable [...]
Again I don't use this personally. In reality navigability should be derived from the underlying behaviour. Does it require navigating one way/both? Then set navigability accordingly. However some people like to specify it explicitly, on basis it makes the implementation clearer (If only navigable one way it can be implemented with reference(s) in one class only; if bi-directional it needs references in both directions - with attendant logic to keep things consistent).
Multiplicity
I agree with your selection.
Hope that helps.
When creating relationships in an Object Class Diagram for an Object Relational Database, should the diamonds on the ends of the relationship links be filled in or not.
Here is an image of my Class diagram:
http://canning.co.nz/Weltec/Class_Diagram.png
It's a choice between Composition and Aggregation, which Wikipedia explains quite well.
In practice though, I think a valid answer is to just not worry about the difference, unless it's a school assignment. I've found that trying to make very detailed UML diagrams isn't terribly useful in practice.
Composition relationship has a coloured diamond shape structure ending at a class if it belongs to a 'is a' relationship (i.e- the entity cannot exist without the parent class) whereas the aggregation has an empty diamond shape ending at a class if it belongs to a 'has a' relationship (i.e- the entity can exist without the existence of the parent class.
A full diamond denotes Composition, or a 'owns' relationship. You use it when the referenced entity can't exist without the class representing it. An example would be order to order item. The order item just doesn't make sense without the order.
An empty diamond denotes Aggregation, or a 'has' relationship. A quick glance at your diagram makes me think this is the correct diagram element to use in your case.
But I agree with #mpartel: If there aren't any specific requirements to distinguish between the two just ignore the diamonds.