I am having some troubles with Composition and Aggregation relationships in UML, I do understand the whole/part relationship so if a class cannot exist without its whole then it makes it a strong composition relationship and if it still can exist without its whole then it makes it a weak aggregation relationship.
However sometimes it gets a little more tricky than that when dealing with real software requirements. I have a class diagram below with all necessary, attributes, operations and properties included which are all correctly shown in UML standards however I am unsure about my relationships:
1 Interface and 6 classes
Could someone confirm if my relationships are correct or not?
Many Thanks
There are a few issues. The best example of composition is Maze to Location. Your connector has the diamond on the wrong end. The class that consists of the other class has the diamond, so Maze consists of Locations. Maze should have the diamond.
The Species - Snake relationship is suspect since there are many species besides snakes and species don't consist of snakes. I also don't think that Explorer consists of Stones. The explorer-stone relationship is a straight (if I understand your application) 1 to many relationship.
I would also add multiplicity to the diagram to clarify 1:1, 1:many, etc. Please correct your diagram and repost.
It is vice versa. The black rhombus should be at the side, that holds or simply is the set of the objects from the other side of connection.
Also an occupant can exist without location (an explorer before the adventure), so it is rather aggregation dependency, not composition. As for maze, the maze IS a composition of locations, OK. Explorer to stone dependency is again aggregation - stone can be without Explorer easily.
Also, I am not sure that stone should descend directly from Occupant. I'd define CaveObject class (because Object is already busy) and derive Stone and Occupant from it, and Snake and Explorer from the last. And I'd add an interface TemporaryOccupant, and make Explorer to implement it. In that interface I'll put functions to move from one location to another.
As for Species/Snakes, I am afraid, I am at lost - what belongs to what? Rather, species should be another interface and both the snake and the Explorer should implement it, too.
BTW, I see here another error: You connect Snake and Species - it IS an attribute of other class with the type of another class already. Don't declare it as one more parameter in the class rectangle.
Your Explorer has only getter for Name, but no Setter. Your drop() has no parameter to set what will be dropped.
Related
I have a class diagram like it is shown in the picture.
There is a Controller that has some TopicLoaderIF and several TopicReaderIF classes. The TopicLoaderIF creates a series of TopicIF upon request from the Controller. Then the Controller forwards these TopicIF to the correct TopicReaderIF. Let's not enter in weather these model is correct or not but in the relationship between them.
The thing is that I have been trying to model this as an UML class diagram but I am stuck thinking on the kind of relation between the Controller and the TopicIF (in red), if there should be any in the diagram. Further more, I am also not sure if it is correct that all three, the TopicLoaderIF, the Controller and the TopicReaderIF, have a direct associations to TopicIF. Should they be just a normal association, without the arrow?
I would appreciate any advice you may give me regarding this diagram.
Navigability expresses A can see B if there's an arrow from A to B. In a rough sketch these arrows can be helpful, but are not mandatory. If the arrow is not present, both classes could see each other, but must not. When implementing such an unspecified association you will judge at the needs and only implement needed references (if B has no need to see A you would not implement a reference).
Once you are going into detailed design, you will start using role names towards the ends. This makes perfectly clear how navigation will work.
TL;DR When sketching, use arrows. Once starting with details, replace them with role names.
This question already has answers here:
What is the difference between association, aggregation and composition?
(21 answers)
Closed 6 years ago.
I'm having some trouble fully understanding composition and aggregation. From what i'm understanding a composition relationship means if one dies the other dies. aggregation means they're formed of that, but not necessarily dependent on that things continued existence.
This is the UML I put together for a game of hearts. Am I grasping this concept correctly?
What is composition and aggregation ?
The composition and aggregation represents a whole/part relationship (UML 2.5, section 11.5.3.1):
A binary Association may represent a composite aggregation (i.e., a
whole/part relationship).
So if you use a diamond, you should first ask yourself if it's really a whole/part relationship, before thinking how objects are created or deleted.
Then composition have additional constraints over a shared aggregation. In a composition relationship (UML 2.5, section 9.5.3):
(...) the composite object has responsibility for the existence and storage
of the composed objects. Composite aggregation is a strong form of
aggregation that requires a part object be included in at most one
composite object at a time. If a composite object is deleted, all of
its part instances that are objects are deleted with it.
Analysis of your specific diagramm
According to your diagram:
The players exists only within a game (i.e. temporary identification not accounts existing across several games). The composition could make sense, as players can be seen as parts of the game.
The hand exist only in relation to a player. That makes sense. But is it really a composition relationship ? Is the hand a part of a player ? Is the player composed of hands ? Wouldn't a player have several hands sequentially but not in the same time ? I really have my doubt about a composition here; I'd represent this with a normal 1 player to many hands association.
The game aggregates several decks. I don't know your game but I'd expect one deck. If several decks are used, and the decks only exists within a game (similarly to the players), I'd rather see a composition instead of an aggregation. Alternatively you could mean not the deck, but the deck together with its state. In this case, I'd opt for a one to many association and not a composition (the deck+state would not be a component of your game, but define the state of the game).
A deck is the aggregation of cards that exist independently of the deck. This troubles me a lot, as my world experience has always shown that a card is part of a deck. If I find an isolated card somewhere I always look for it's deck. I'd therefore rather expect a composition between cards and deck.
Finally a hand is the aggregation of several cards, which seems to make sense. Note that this is not incompatible with a composition between the deck and the card.
Suppose that F16Weapon and F18 HornetWeapon are the two weapon class.They have three weapon such as connon,bomb,missile for each class.
I am tiring to draw a interchangeable relationship between F16Weapon and F18 HornetWeapon.I mean F16 class can use F18 weapon set or F18 class use F16 weapon set. Basically If F16 class try to use F18 cannon weapon , F16 will use it easily from F18 Weapon set. Same thing will true for F18 class. So there will an interchangeable relationship between F16 class and F18 class. How can I represent this interchangeable relationship between two class in UML class diagram ? Anyone can help me please.
Thanks in advance.
xmojmr is right that you should use generalization. The point behind his answer is that generalization is a way of pulling like behaviors from a group of classes and making them into one class that they all use. This is pretty much what you have described here.
Now, if the cannon uses the same software when using the F16 and F18, then you might want to keep that software in one place and let both of them use it. If, instead, you want them to use different software, and then use a third piece of software that deploys the cannon without having to know whether it's using an F16 or an F18, then you would use an interface. An interface says if you want to be a CannonDeployer (or whatever) then you have to make a Deploy method (or whatever) available, but you can write it up any way you want.
So, as he says, an interface is more flexible, but you have to decide whether you need to go to the extra work of providing different implementations of the software for each plane. If you don't, then put the implementation in the base class (FXCompatibleWeapon in xmojmr's example) and leave it at that.
I'm developing a game in Java which I can only describe as a variant of The Sims.
The main interface for the game consists of a level and will have a large variety of furniture which can be placed on the map. My problem is that whilst I can think of ways to construct a system which will allow me to assign properties to each item of furniture, I want to make sure I do it the correct way before I head down a long path to completing it. For example, if I referenced an object with an identifier of "sofa", the furniture object's members could be accessed through searching through all available objects and finding the one with the matching identifier.
My method would be to make a very large .java file with instances from a base furniture class for each item of furniture, with each one having an identifier and all its different properties assigned, such as image, position, rotation etc, plus their own unique code for each different function they provide (eg. sitting, sleeping).
For saving/storing these objects in a text file, I would just store the name of the identifier in the string array in the text file and when loading, I could just create the object by instantiating the object the identifier points to.
Would I be correct in using most of these methods, or are better ones available? If you've found it a struggle to comprehend what I've written (and I had trouble writing it clearly), then a more simple question would be:
How are items of furniture managed in The Sims with respect to the sheer amount available and the many different variations/rotations they can be placed in (and stored/saved)?
I think what you need to do here is try and abstract as much of the common functionality to the base classes and then each item should extend as necessary.
Eg
A Sofa... Seat extends Furniture extends Object
A Office chair would be the same
A DiningTable would be different tho... Table extends Furniture extends Object
You will also want various Interfaces so that a Sofa implements Sittable think of the functionailty that might be common to different objects, like they might all be Placeable
Also for saving and loading you might want to make your objects serializable.
Read up on Abstraction, Interfaces and Serialization
Component-Entity-System may be a good thing for you to look into. It's basically what you're describing. There's a large collection of entities, each entity has a collection of Components, and there are systems which know what to do with certain components.
EG: A piece of furniture is an entity named "chair". It has many components, one of them is "Renderable". And your game loop passes all renderables into the "renderer" System which calls the Renderable.render() method.
Note, this isn't very object oriented, but I find it's tough to design games like this in an OO way because the object hierarchies explode. Everything has some things in common with everything else. You'd end up with generic classes like "Unit" and "Thing" which isn't very OO either.
I'm making a simple 3D CAD software. in the class diagram, many objects need to distinguish with others by (x,y,z). I create a class so-called "Position", but the problem is it looks highly-coupling because many classese work with position.
Any ideas?
It is not a problem per se if a type is used by many other types. In your case, graphical objects obviously (usually) have a position so the coupling looks natural and reasonable from the perspective of the domain model.
Also, the Position class is probably going to be a fairly low-level class whose interface (and probably implementation too) is not going to change very often in the long run. So there is not much chance of such changes breaking client code.
First let me say after 12 years that your design is not bad. Assuming that the positioning logic of your classes shall be called from outside, all your classes need to have and offer this logic. So it is part of the interface and you must bring the functionalities in. And this means, you must depend on it and there is a coupling. The coupling is not between your objects. So it is not as bad.
But there are always alternatives. It is known that inheritance establishes a very tight coupling. Consider for example that the positioning logic is only called internally in your class. Then you don't have any benefit in inheritance. You could as well have another class (let us call it Position). And instead of deriving from this class, you integrate an object of this class. And whenever you want to do something with the position, you call the corresponding methods of this object.
This alternative looks like a nonsense change. Why should you do this? But let us have a look at the consequences. Assume you have a class Circle. Circle has such a position object as proposed above. (By the way, see the wording "has a position" instead of "is a position". The "object-and-composition" solution seems to be quite natural.) Somewhere in a file X of your code you may have created such a Circle. And now you decide you change the positioning logic. In X you don't have to worry that this has a side effect, because the interface of Circle has not changed. It is just one object inside of Circle that has changed. That is just an implementation detail. In contrast if you would have used inheritance, you cannot just change the base class without looking if this has a negative effect to X. So this "object-and-composition" solution has actually reduced the coupling between X and the positioning logic.
You can even reduce the coupling further. With the object-and-composition solution, whenever you change the positioning logic, you have to check all your classes if this has an effect. But what about using an interface for Position. Your classes don't see an object of a type Position, but an object that fullfils an interface Position. And the actual positioning logic implements this interface. This way most of your classes' code has no dependency to the implementation of the positioning logic.
That is not the end of the game. There is still a coupling, because your classes must somehow create the position objects. So at least the constructor must go into detail and for example pass x,y,z. But what if you use something like a factory for this purpose, so that your objects just get the position without even knowing how these have been created. Then you are absolutely flexible. You can use your classes in completely different situations. For example in a two dimensional coordinate system. There is no coupling between your positioning logic and your classes any more.
I hope you see that all these options exist. I suppose in your example this is a bit over-engineered. But your question was how to reduce the coupling. And there are always ways. Combinations are of course possible. For example you can have the object-and-composition and make the position object public in your base class. But then I would ask if not inheritance would have been the better option?