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.
Related
I am designing a UML for my JAVA program class. It has 50+ attributes and 50+ properties. I have to include the UML in my report in word document. Is there any problem if the diagram gets split into multiple pages?
20+ properties have getters and setters, so it is necessary to include them?
And there are few other classes with which I have to show the relationship, the relationship diagram will be on another page, so on relationship UML do I have to list all the attributes again ? or I can just include the class name in the rectangle?
If your diagram contains only one class, what's the point of it. Maybe it's better to put just a textual class description?
On the other hand a single diagram spread across few pages isn't really readable anymore.
UML specification explicitly says that you place on your diagram only what is needed and useful in a specific context. You may put just a class name on other diagrams and that's fine.
Other option is to depict your class with properties and operations important from the perspective of specific interactions. You can show that the list is incomplete by placing an ellipsis after the last feature in each section.
If I had a case like you I would very carefully examine my design looking for flaws in it. A class with that many features can hardly ever be justified.
I'm trying to create a Entity for a game that uses both the Component and State design patterns. Let me explain.
The Components that make up an Entity will consist of an InputComponent, PhysicsComponent, and a GraphicsComponent (for now). Each Component will their own class to keep the clean nice and decoupled. This way you can implement your own components like for example a PlayerInputComponent to represent player input, and then create an Entity like this -> Entity player = new Entity(input, physics, graphics).
This system alone works really well for decoupling the code that makes up an Entity. It makes the Entity class flexible enough to accept all different types of components allowing for many variations. However, as stated in the question, I also want to use a State design pattern and I can't think of a way to make them coexist nicely.
The State design pattern is going to be used to represent a finite set of states that an Entity can be in. For example, there would be a RunningState, IdleState, JumpingState, etc... These states would be able to process input and update, deciding when to change states, and what state to change to. For example, if the movement keys are pressed in the IdleState, the IdleState would process this and decide to switch to a RunningState. This makes keeping track of animations easy and separates out the logic for changing states into their own class avoiding complex logic statements.
My question is how can I mix both of these patterns so they work well together? I need all Components to be able to access these States because state transitions may occur in the InputComponent or the PhysicsComponent (for right now), and the states also have to be accessible in the GraphicsComponent so I can draw the right frame for the current animation.
What's the best way to setup my Entity class so it can implement both patterns and have them interact with each other without creating a mess in the Entity class. Thanks!
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.
I am trying to confirm whether this statement is true:
Model includes both:
persistence layer: essentially DAOs + classes representing tables + DTOs
service layer: Combinations of DAOS + some logic
Could you also please reference/support your answer? I believed I've seen in Spring Framework good diagram, but no matter how searched this time I can't find it.
And the other point: I was always wondering why we abstract stuff so heavily that at some point people just stop understanding, is it done to increase our own value? :\
For example analysing Spring MVC I can say that central piece is controller no matter how you name other layers it is Controller who decides where to go what to extract , how to validate it and which view/controller to pass it on. Yet this simple statement is never found in formal articles keep confusing people.
So Controller is our god. Controller asking for some method within a class that call methods of another class. On top of it all is wired with dependency injection as we only need a single instance for objects of singleton nature. Controller>Service>DAO that's it .I would really appreciate book written by pragmatics.
If people would write books based on how things really are and not how to make look them beautifully drawn in diagrams or written the endless questions as such would never raise in a first place. And I thank stackoverflow for people that always show me the path. ;-)
MVC and the DAO/Service architecture are less concepts which are contained within each other than which sit next to each other.
In MVC, your controller takes care of fetching all the data, placing it in a model in some way, and passing the model to the view to be rendered. If you are also using DAO/Service architecture, your DAOs/Services might return an entity which contains all the information you will be displaying on a given page, and people often use these as the model for the view if things are relatively simple.
The problem with this tactic is you end up having dependencies between your views and the specific implementation of your model. Also, if you later decide you need some extra information which is not included in your model, you'll have to rewrite your view to account for this. This is why it is often suggested you do as much preparation of your data in your controller before passing a very simple model (a Map) to the view.
Here's a diagram showing the separation of layers:
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?