This question already has answers here:
UML aggregation vs association
(8 answers)
Closed 4 years ago.
is there any why to know which one of two types of interaction
mentioned[aggregation or association] should be used in class diagram
?
is it even matter to specify which one to use in a certain interaction ?
Assosiation
The most abstract way to describe static relationship between classes is using the Association link, which simply states that there is some kind of a link or a dependency between two classes or more.
Aggregation
In cases where there’s a part-of relationship between ClassA (whole) and ClassB (part), we can be more specific and use the aggregation link instead of the association link, highlighting that the same ClassB instance can also be aggregated by other classes in the application (therefore aggregation is also known as shared association).
If you want to read detailed description then check this LINK
Related
This question already has answers here:
Aggregation vs Composition
(3 answers)
Closed 4 months ago.
I am having trouble finding the right and easiest answer to the above question.
Can you please answer my question.
There are many kind of answers to association Vs Composition Vs Aggregation.
One is plain and one is hollow ;-)
Indeed, the UML specifications let the semantics of aggregation very hollow, that is unspecified. More precisely, page 112 of UML 2.5.1 about ("shared") aggregation and composition ("composite aggregation") says:
Shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
Composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects.
Jame Rumbaugh, one of the UML founder even called aggregation a “modeling placebo”, i.e. some feel better when using it even if it does not add any useful information (the exact quote here)
P.S: you will find lots of misinformation on aggregation. Including the most voted question on SO about it. But it's not a question of belief. UML is a standard (even an ISO standard), so always verify that claims are backed by authoritative references
This question already has answers here:
Why does Mongoose have both schemas and models?
(6 answers)
Closed 8 years ago.
i'm suprised this question hasn't been asked before, makes me kinda worry actually about my ability to understand how things work on my own....
In object oriented programming, we firstly define the abstraction, the class, and then we instantiate many concrete objects, based on the abstraction.
Why do we need to define both a Schema and a Model with Mongoose ? Aren't these 2 steps the same thing ?
The simple reason is that "model" and "schema" are two totally different things.
A "schema" defines the type constraints and other logic than can refer to how you want to "define" an object. Thee are many methods to do this including basic type rules right through to defining certain methods for validation or even dynamic field construction. A Schema is basically a extended definition of an object.
A "model" is something that actually "ties" to storage. In that it means there is something defined in "where" to actually store the the information. The "methods" used to interact with storage are also generally associated with a model. So you can save, or find or delete based on the model association. A "schema" can therefore be "tied" to various "models", as a model is all about a storage location.
So in the basic mongoose sense, a "schema" is not something that is necessarily tied in a "one to one" relationship to a "model". A schema can have many models and therefore the separation is made.
Okay so I'm a bit confused as to when I should add an attribute to a class vs drawing an association to a class when trying to show a relationship in a UML diagram.
For example let's say I have a DFA class that contains 10 state objects each having a different set of paths to various states in the DFA. Should I draw the composition line from the DFA to the State class or just type all 10 states in the attribute section of the DFA class.
Basically I'm trying to figure out if when a Class A contains (or is composed of) one or more Class Bs, should I draw a line (aggregation, composition,association dependency etc) between them or just put one as an attribute to another.
This article attempts to answer the question but I get confused as soon as he starts talking about the diagrams he drew.
The article you pointed gives one guideline:
In the years I’ve been working with different modelling teams I’ve found that the rule that works best is to use Associations for Classes and Attributes for DataTypes.
A data type is a special kind of classifier, similar to a class. It differs from a class in that instances of a data type are identified only by their value.
I kind of agree with the author, adding another point: your class diagram should be understandable. If you have a diagram with many lines crisscrossing each other the diagram is useless. When this happens you must try to find relations that can be modeled using attributes without loosing too much visual information, and replace them with attributes.
Another thing that you can do with relations and not with attributes is to display bi-directional relations (you can do this with one attribute in each class of the relation, but you loose the semantics of the relation).
Sorry for this newb question, i'm new to UML.
The diagram for a system is this one:
From what I know of UML, none of the classes in this diagram can own instances of the associated class as there's no aggregate relationship with it.
Does this mean in an implementation of the system in Java, based on the diagram, an outside class has to own instances of the associated class?
Sorry if the answer is obvious. I've spent hours scratching my head over it.
First off, terminology. #Daniel is right, you don't have an association class. However, I don't think you mean Association Class:
Does this mean in an implementation of the system in Java, based on the diagram, an outside class has to own instances of the associated class?
If I understand correctly that's the nub of your question. In implementation terms, which class(es) have a member variable containing a list of references to instances of Associated Class?
Again - if I understand right - your question stems from the following logic:
In UML, "ownership" is commonly described as a quality of Aggregation (or Composition) relationships.
The relationship between Aggregated/Composite PART Class and Associated Class is a simple binary association - not Aggregate/Composite.
Therefore the "ownership" property doesn't apply
Therefore who owns the list of references to Associated Class instances?
If that's right then the issue is with the specific meaning of "ownership". Whilst not tightly defined in UML, "ownership" typically means responsibility for managing full lifecycle.
I think you're interpreting it more generally: that if an association isn't aggregate, then the participating classes can't hold references to each other.
That's not the case. It's perfectly reasonable for Aggregated/Composite PART Class to hold a reference (or list of references) to instances of Associated Class. The inverse is equally valid. In some cases both are valid (with the attendant need to maintain consistency).
So in summary: is it necessary for an outside class to own the instances of Associated Class? No. It's perfectly valid for either or both ends of a binary association to manage instances of the relationship.
hth and apologies if I misunderstood your question.
PS: a final observation: be very careful about what you mean when using Aggregation. It's notoriously imprecise in the UML spec. Composition has a more rigorous definition, and you can cover 99% plus of all modelling scenarios using Composition and plain Binary Associations. About the only place Aggregation has a well-defined meaning not completely covered by the other two is denoting when recursive relationships must be acyclic.
UML does not specify the full behaviour of a system. So what do you mean, when you say an object owns another object? Also instances AssociatedClass could be root objects that are not owned by any other object.
The diagram you provided doesn't really contain an association class. The class you named 'associated class' is just a normal class. It also isn't owned by anything (that we see in the diagram).
If what you had in mind was association class, then take a look at example diagram with association class:
In this example, the MilleageCredit is an association class. So for each distinct combination of Fligh-FrequentFlyer there is one MilleageCredit.
As for ownership, since the Association class represents a relation between 2 associated objects, it gets deleted when
the association is cleared
either or both of associated objects are deleted
So if you delete either the Flight or FrequentFlyer the MilleageCredit will be gone too.
Also if you unlink Flight from FrequentFlyer again the MilleageCredit will be delete.
There's plenty of good UML docs online, for example UML basics: The class diagram
Hope this helps, otherwise please provide more info in the question.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have a small program to build a house. A house will have many floors (storeys), a storey can have many rooms, a room can contain many items. So I tend to use the Decorator Pattern for this program. Here is the initial design:
http://img337.imageshack.us/img337/5530/maina.jpg
Can you help me to improve the design?
In object-oriented programming, the decorator pattern is a design pattern that allows new/additional behaviour to be added to an existing object dynamically.
This how wikipedia starts it's article on the decorator pattern.
So the decorator pattern is about adding behaviour to an existing object. And items in a room are not an additional behaviour for that room.
I think, the Composite pattern would be a better choice to build a model for that domain.
(But if you still want a Decorator for your house you may find a better solution here ;-) )
I dont think decorator is the right pattern here.
What I'm seeing the design is multiple instances of "is-a" and "has-a" relationships.
An "is-a" relation is a specialization. Examples : "Bungalow" "is-a" "House", "ConcreteRoom1" "is-a" "Room".
"is-a" relationships are implemented using inheritance. In some cases, favoring composition over inheritance, "is-a" maybe implemented using decorators.
Ideally, the "Room" or "House" constructs must be interfaces (or abstract classes), which define object contracts and base properties
The concrete implementations of these interfaces are the actual objects that you will work with.
A "has-a" relationship is a composition. Examples : "House" has "Floors", "Room" has "Items"
Generally, a has-a relationship maybe implemented by storing attributes for each object that your class "has".
it is always a good idea to store the attributes as a collection of the interfaces - e.g. Room should have List<Item> items
Hope that clarifies the usage expected in your design.
I see a lot of inheritance here. Decorator pattern dictates lesser inheritance and more composition. So you create decorators and embellish your objects at runtime. See Decorator Patter.