I seem to have a problem about a simple time tracker. The way its set up is that a user can track hit time related to a project or type in something freely. This means that a timetrack object always has a user but does not always have a project. The inconsistency can occure when I create a Timetrack object in the database connected to a user, but then connect a project that does not have a association with the user to the same time track object.
Whats the best way to fix this. I've heard about directional association but I can't figure out how that solves the problem
class diagram:
I don't understand your explanation of TimeTrack, but I think that your modeling problem can only be solved by adding an integrity constraint (called "invariant" in the UML) requiring that the time track user is a member of the set of the time track project's users.
This can be formally expressed as an OCL invariant in a constraint box attached to your TimeTrack class with the following expression:
self.project.users->includes( self.user)
Instead of OCL you can also simply attach a constraint (note attached to the related connector) containing something like:
{association can only exist if there is a connection between project and user}
Related
I've never made a class diagram before, that's why I tried to ask. I always learn from my mistake. I have read some references, but I am confused how to test the results I made? because this is not a coding which if have error, the error message will be appear.
this my design database
and this is a class diagram that I made based on design database.
is the method for creating class diagrams similar to erd? I am very confused how to inherit the class and which arrow should I use?
in the path that I made there are three users. and each has a different role
Public Relations = Input data from external user (the applicant comes and gives a written proposal) then the data is stored in the database. The data includes applicant data and proposal data. PR can also see data that has been confirmed by the Division
Division = The division can see data that has been stored by PR and confirm the data. Data that has been confirmed will be filed and made a report.
Manager = can only see reports
Here are a couple of findings:
User->Login: This is no generalization. A user isn't a login. It might have some login information associated. So that shall be an association.
Similar for Proposal->StatusProposal. But here it's a dependency since you will not create an enumeration object. You just use it to type an attribute.
Same for User->Gender/RoleUser. Both are dependencies.
There are also a couple of design issues. But here YMMV too much. Having User implement userLogin() is at least questionable. There should be a security system taking care which validates a user login. So why does Login have a loginStatus()? However, design is not be discussed here.
As to class/ERD: they are similar, but not the same. UML has a broader scope while ERD focuses plainly on databases. So all the *_id attributes in your classes stem from a database design. The class design in that state is very much focused on databases. In a MDA it might be derived from a PIM to a PSM (so from an abstract view to a DB-specific one).
In addition to Thomas Killian's observations, your composition associations appear to be inaccurate. In effect, for example, you are specifying that the lifetime of a Department object is dependent on the lifetime of a User object. You are also specifying a whole-part relationship between Users and Departments, where the user is an aggregation of departments. I would think that it's the other way around. I also suspect that a user's lifetime isn't dependent on a department's lifetime, since a user can typically change departments. Therefore, an aggregation diamond (white) is probably correct, and it should be on the Department end.
Similarly, I have trouble making sense of your other two composition associations.
I was wondering if it was possible to have differences between my conceptual model and the class diagram?
In the conceptual model, I explain that the user can create a message.
But in the class diagram the user must go through a class that contains all methods of creating a "ManageMessage" message.
here is an example
Can you help me ? Thank you
It's up to you how you show your classes in different diagrams. So in one you can show detailed attributes and operations and in another you show just the class name. However, in most cases it's better to create domain model which focuses on business aspects in the beginning. It does not have technically imposed structural elements and mainly you use attributes (YMMV). Later you derive a technical design from that model where you create a copy that links back with <<trace>> dependencies (UML tools offer transformation for that). Although you have to (mostly) manually synch the two models it's best to communicate with either business and developers.
N.B. about your design above: A message with zero related users does not seem to make much sense. Also you should not use the shared aggregation since it has no defined semantics.
I am working on an online web store. It's a simple web store and I have to create domain UML diagrams for the class and show multiplicities. I am kind of confused about the multiplicity that I have came up with. I don't know how to distinguish between composition, aggregation and association. Below is the diagram that I have came up with. Can someone tell me if I am on the right track?
http://i.imgur.com/8FwhsaI.jpg
Not too bad. You should not bother to much with aggregation unless you need to deal with memory management or foreign key constraints in database design. Just leave them away.
One important change you should make are the role names for associations. E.g. instead of shippingAddress:Address declared as attribute use a role shippingAddress appearing near association on Address that comes from User (etc. for the other ones).
Since Address is sort of a common-place and used all over, you could leave the class out of this diagram and make a separate diagram where Address is in the middle and all others using it surround it.
I agree with Thomas, but I will show other points so can you adjust your diagram.
Please don't see as something destructive. I just believe these tips can help you.
show multiplicities of every connection
do not use getter and setter *
do not use ID's attributes *
Order makes composition with User (does not make sense have an order with a user related with it and OrderLine makes composition with Order;
Product make aggregation with OrderLine and Review make composition with Product;
Manufacturer makes aggregation with Product. ( depend on your system, it can be a composition, but it more likely to be an aggregation).
Remember (the part) makes something with (the whole)
it does not need to create an attribute in a class if you have a connection with that class, except when you have a list of it,( e.g.1: attribute CreditPayment in Payment and Class CreditPayment );
You could make a List of Product in Order. After this, you could delete the Orderline Class.
*if you will not generate a code from the model.
In my system, I have some entities that conceptually inherit from User. For instance, I can have suppliers and regular consumers. I wish to extend the User entity, so that I can inherit all of user benefits like register, login, lost password and so forth.
I though about a few options:
1. Extending the User entity using one of the Hibernate inheritance strategies (https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/inheritance.html), but it looks like a lot of changes in the code is needed. I'd also have to make sure the tables generation would be also correct and working fine with liquibase;
2. Adding all necessary attributes to the User entity and then adding suppliers and consumers as roles. I just don't feel comfortable by doing this since the User table wouldn't be normalized;
3. Creating a relationship from each of these entities to the User entity, but in this case, I don't clearly see how to inherit the user management benefits.
Has anyone ever done something similar so that could shed some light on this?
Thanks in advance.
I would rather use composition over inheritance. So basically, you would have Supplier holding a one-to-one relationship with User. This way, you let JHipster User related code unchanged.
User management feature has not yet been released so let's focus on user registration then how would a user qualify as a supplier or customer? Are they supposed to choose by themselves? Can a user be both a consumer and a supplier?
For me the simple JHipster CRUD screens will not be enough, you must be prepared for building your own screens for better UX. So, I would rather focus on having a strong data model and REST API.
I found a way following the second approach.
I added all the attributes for each subclass (in my example, Suppliers and Customers) to the table User (JHI_USER) and a type attribute as well so that I can know which type of user I'm handling. I added also their respective attributes to the User class and updating the related classes, like UserService, UserRepository, test classes and so forth. I used the concept of roles too, but just to provide permissions to each section of the site.
After that, I created an AngularJS state for each user type, passing its type (kinda like a discriminator). For instance, I created a state called /registerSupply passing its type = 'S'. I then edited the original register page to add all the additional suppliers and customer attributes, filtering them out based on the user type and that is it.
As I stated, I don't feel comfortable by using this approach, but in the end, it's basically one of the strategies suggested by Hibernate (https://docs.jboss.org/ejb3/app-server/tutorial/singleinheritance/single.html), which makes me feel a bit better.
The preferred way explained in this issue is to use Git. Just add your code manually, and use git merge when you regenerate your code from JDL.
Using composition would create a JOIN that has performance impact on a massively used entity. Entity inheritance works but is hard with JPA and would even harder with generated code.
If I had to choose between composition and inheritance, I would prefer here composition with caching when the application grows.
Given the following Entities:
Container
User
Client
Institution
The Container entity has an association to one or more parties through the property AssignedToParties.
Container.AssignedToParties can contain a mix of Users, Clients, and Institutions.
What is the recommened domain model for this relationship.
I had considered the following options:
1) Create separate properties for each type:
Container.AssignedToUsers
Container.AssignedToClients
Container.AssignedToInstitutions
This seems pretty inelegant, but does not require business logic to check the types or do any downcasting.
2) Create a common base class "Party" for User/Client/Institution
Container.AssignedToParties would then be a collection of Party entities. This seems like an akward solution since the Party base class wouldn't have any methods or properties. I'm also not sure I like the idea of adding one more layer of inheritance here.
This solution, like #3, would require the system to check the types at runtime to make decisions and then downcast to either User/Client/Institution to process them.
3) Create a Marker Interface IContainerAssignable that User/Client/Institution implement
This would at least provide some type safety, but would require type checking and downcasting.
Right now, I'm leaning towards #3. It seems the simplest, but I've read in quit a few places that if your code is running logic that has to test for a given type and downcast that you probably have a bad design.
Any advice appreciated.
Based on your comment in response to my question, I would not have the assignment handled by the container at all. To use your example, a file doesn't know or care who's watching it.
Instead, I'd either have the watcher implement some method (or collection property) to start watching a container (and in that case, making them an IContainerWatcher or the like would make sense), or else have that watching functionality offloaded entirely into a service that's dedicated to maintaining the associations, like a publish/subscribe mechanism does. This is conceptually analogous to a many-to-many join table in a database schema.