I have made this simple UML diagram.
I want to have a list of treatments inside class Customer.
My question is if I need another association to make this possible.
A class diagram describes classes and not objects. A TreatmentList is a TreatmentList, regardless if you look at it from the Menu or the Customer persepective.
So indeed, if you want a list of treatment "inside" the class Customer, you'll need just to add another association between the classes you want to connect.
Now I wonder if you did not try to design user interface using a class diagram:
Main -> Menu -> List 1 or List 2 looks terribly like a flow in the user interface, more than a set of related classes. You don't need this. And lass diagrams are not meant for this purpose. If you want to model an UI Menu, you'd model a menu class, i.e a general class that could instantiate any kind of menus, with a one-to-many association with MenuAction. Perhaps ShowTreamtmentList would be a specialization of such an action.
The TreatmentList and CustomerList only make sense if these are classes, i.e. they could be instantiated into one or several objects that each represent a different list. If, for an association, you'd have a multiplicity of * on the side of customer or treatment, you would not need to add a special list/set/bag in the middle.
You don't need to use an aggregate instead of an association. Aggregate are not very uselful and appear to be overused. Prefer a simple association.
Related
Let's say,
we want to build some system like Ticket Booking (ticket booking is not the key thing here, it's just an example)
So we have a User class, Ticket class etc
We also have a TicketService class which provides methods for bookTicket() cancelTicket() etc etc
In the class diagram, TicketService should be included or not?
If not, where should the bookTicket() or cancelTicket() be shown on the class diagram,
in the Ticket class or the User class(since user creates the ticket)
This depends on what you want to represent. If you are wanting a faithful representation of your code in a Class Diagram then yes; if you are simply wanting to explain the logic of your business domain (i.e. the business entities in the domain) and you don't want the clutter then no you could drop the service class. This is subjective/opinion based and depends on what you need to do.
If you want to avoid the service class but you want to represent the logic of the domain with behaviour, then you could simply add a "book ()" and "cancel ()" operation to the Ticket class. This would be the standard approach in object orientation -- i.e. encapsulation of behaviour (and data) within the object that is responsible for it.
In UML diagrams when considering composition. Should we use it in logical or implementation sense. Examples for both terms:
Implementation - An airport will contain a reference to the country. In other words, a country is part of the Airport.
Logical - A country can have zero or many airports. In other words, an airport is part of the country.
From diagram above, which case shows correct usage of composition?
NOTE: if neither of these cases are good, please suggest other ways to show relationship between country and airport.
I think that this is not a composition in the strong "UML sense" of that word.
From wikipedia:
The relationship between the composite and the component is a strong “has a” relationship, as the composite object takes ownership of the component. This means the composite is responsible for the creation and destruction of the component parts.
An Airport does not create countries (and in IT sense, a "country" object is also not responsible for providing/creating "airport" objects).
In that sense, you are looking towards an association here; and I think the first one fits better (talking in "general"). But the core aspect is: your model has to express the specific requirements of your domain. In other words: both solutions are valid; it very much depends on the context which one to choose. So, pick the one that helps you solving your problem!
This would depend on the ultimate model you're trying to build.
If your model includes countries as first-class objects or entities then clearly a country contains airports. If Country is an attribute of an airport (more properly an attribute of the airport's location), then model it as such.
Unless you have a good reason to model countries as entities I'd go with the attribute, since borders can shift and airports can change countries.
In other words, this question doesn't have a definite answer, either can work depending on your ultimate goals.
If I can suggest :
cf. Section 9.5.3 of UML specification (march 2015) :
Composite : Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
and
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.
For me, the question of implementation and logical is more a question about db model. But maybe I am wrong.
And If I have to do a choice I will design the implementation case only.
You can say that airport is a part of a country or in other words is responsible for it. So from business perspective the second approach is correct. To indicate the "knowledge" about the country from airport perspective you can add an open arrow pointing in the country direction just before the diamond.
Regardless of the approach what exactly you want to model the first diagram is incorrect. With this diagram each airport will be responsible for one country so each airport will be in a different country.
I have a class called Member which I use as the model for one of my views. This view allows the user to view and edit details of a particular Member. My question is what model should I use for a different view that allows the user to add new members? Should I use the existing Member class and adapt it for this use, or should I create a new model class dedicated to adding new Members, and if so what should it be called?
If I understand you right, you have a class Member which does, contrary to what one might expect reading the class name, not represent a single Member but rather a MemberModel. This could be a mere naming issue.
Suppose your class Member has the capability to add, edit and grant access to particular members (directly or indirectly), it would make sense to adapt your existing model class so that it supports adding new members- for example by adding a method addMember() which can be called by the corresponding views.
It is fine to manage the functionality of accessing, editing and adding members via a single model. The model provides methods to your views which enables them to access, edit and add members and makes it possible for views to listen to changes of the model they are interested in (e.g. via listeners).
Depending on factors like the complexity of your project it could in principle make sense to divide your model into submodels, so that your model will be a composition of submodels (represented by individual classes). However, the role of serving as an interface to the functionality of accessing and editing members and the functionality of adding members should be fulfilled by the same class in my opinion.
What i can understand is that you have a class Member which is a model. If you want to use a model to add a member, exposing it in top layers like controller is not appreciated. What you can do is to have a Criteria class or DTO. These classes could carry all the data that is required from the top level to DAO layer.
If this is not what you are expecting, can you elaborate more on your query.
On MVC you normaly use the same model for all the actions that depends on that model. So if you have a member model, it'll be used to create, read, update and delete The famous four operations that are called CRUD.
So yes, the best option is to use the same class, once it will do the conection with the DAO layer of your project. You can fill a member object with information and send it foward to the DAO class that will register it on your dataBase, and then the DataBase can return it empty again for the next use, or don't even return it at all since you probably won't be needing it anymore. It's simple and easy to use.
Some tip about how to best manage the Adding, Editing and Deleting.
Your best option is:
Create a screen that show the user all members and one "New", "Edit" and "Delete" button, on which the New creates a new Member, the Edit edits the selected member, and the delete deletes the selected member.
For this you can create three views (not recommended) or just one, since member will always have the same fields (right? something like "name", "id"...). But one that requires operation as parameter. So you can do something like this:
try {
View frame = new frame("add");
frame.setVisible(true);
frame.setResizable(false);
frame.setLocationRelativeTo(null);
}
catch (Exception e) {
e.printStackTrace();
}
And change "add" to "edit" or "delete" as requisitation. And on the frame called, you can just configure it to as the operation requires.
For example, when writing JPA or Hibernate code, I might want to create a descendant of a domain class, say Account. The descended version represents the a form a show the user. The form only has about half the fields that are on Account. So the object I use to hold the form value should not change the other fields.
Is using inheritance to change annotations considered bad? Assuming it is not, are there any good short hands or design patterns for doing it better or more effectively?
I'd say that the case you describe here (at least how I understood it) would not be a good candidate for creating subclasses.
Basically you want to restrict the form to change only some fields/associations of an entity, right? I further assume that you don't trust the developer of the form that only the fields that should be editable are changed, hence the requirement to restrict that.
In that case, one option might be to use the DTO pattern (data transfer object): create a DTO for the form data and let the user fill its fields. Then pass the DTO to a service which updates the entity accordingly. This way you have control of which fields are editable and how the update is performed.
Another way might be to create a wrapper for the entity that throws exceptions when a setter for an uneditable field is invoked. However, that would be a runtime solution and I'd prefer the DTO approach here.
Edit:
some reasons why inheritance might prove problematic in this case:
The subclasses don't represent entities, however, you'd still have to represent the subclasses on the database (either through discriminators or additional tables)
An entity that is created by that form would always have the subclass and thus would not be editable in other places (unless you mess with the database etc.)
Entities are data containers and should not depend on the presentation. Hence having a special entity (subclass) for one UI usecase (the form in your case) would violate the single responsibility principle and abstraction between model/data and view/presentation layer.
I have little bit confusing many to many relationship between 3 entities. And i want to know how can be my object model look like. I have three Entities, A,B,C and A<->B (M:N) and associate table between both, A and B, is linked with another associate table which make another 1:n relationship with third entity. I have never seen such relationship which make 1:n relationship with another associate table. For further information please have look on following diagram.
Uploaded Image link
If i talk about object model then i will say "INSTANCE_A" has many "INSTANCE_B" instance and vice versa but i do not know how can i summarize relationship for "INSTANCE_C".
Please also let me know whether definition of such relationship between all three entities is right ? i mean is there any problem in relationship design.
Thanks in advance
EDIT: All arrows denote (1:n or m:1) relationship
The data model is correct, but the object model for these tables can be kind of trucky. I'd do something like this:
One class for TBL_A, with a List attribute of TBL_B
One class for TBL_B, with a List attribute of TBL_A
One class for TBL_C_TBL_A_B, with and an attribute for TBL_B, TBL_A and TBL_C
Mapping that in an ORM framework can get funky.
This shall bring you into the right direction. Try to design a UML diagram, or ER should be ok too. Here is some paper with a Model and the corresponding Java-Code for this model http://www.csd.uoc.gr/~hy252/references/UML_for_Java_Programmers-Book.pdf. (Go to -> Class diagrams chapter).