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.
Related
Assuming everyone has the rights to do the CRUD operations (everyone is an admin type user). I have displayed CRUD operations the user can perform in the Domain diagram however, it's become quite messy. I am curious if it's acceptable to do the alternative approach shown in the images below instead since the multiplicative relationships remain the same for each action (create,edit,delete)
Seperated CRUD
Alternative approach? (create, edit, delete)
In short
If it becomes messy, it probably lacks of separation of concerns, or represents associations that are not really needed.
More explanations
Are the associations needed?
An association between User and Xxx implies a semantic relationship between the two classes. This means that instances of the classes are linked and not just for the time of an operations. So x would be able to find the User(s) that updated it, and u would know the Xxx instances that it updated. This kind of association can make sense if you want some audit trails, but this seems not to be your purpose here.
In other words, the fact that a User may perform some operations that CRUD instances of Xxx is not sufficient for justifying an association.
If they are needed, do they represent what you think?
Now it appears that your associations are can ..., i.e. some kind of authorisation scheme. Your diagram tells that each user would need to know in advance all the Xxx that it could update. This is a heavy burden. It would also imply that a user needs to know all the Xxx it can create; before they are even created? This looks somewhat inconsistent.
Modeling an authorisation scheme
If you'd wand to design an authorisation system, you'd probably not link users directly to the object, but use some intermediary mechanisms:
To express that a user can create new projects, you'd probably have some authorisation object that tells the caracteristics of projects that can be created.
To express that a user can edit, update, delete projcts, you could have a direct association like you envisaged, if some admin would maintain such authorisations.
But probably you would have some authorisation object that would tell what a user can do (e.g. a user "role"/"profile") and what category of projects.
Equally probable is that there are some rules that govern CRUD authorisations (e.g. a user having the role "edit" can edit the project he/she is assigned to, but not the others). Making use of such rules instead of explicitly designing (redundant) authorisations could then save you a lot of unnecessary extra associations (and extra constraints to keep the authorisations consistent with the rules).
Separation of concerns
And to keep things continue to be messy, you should consider:
having a separate diagram in your model for the authorisation concept
use some common CRUD interface: the users would then be associated with the CRUD interface without having to replicate everything for every possible class.
The main issue with both of your class models is a confusion between the type/instance levels. Your "can create/edit/delete" authorization relationships do not hold between a specific user and a specific object (an instance of Company, Project or Ticket), but rather between a specific user and a sepcific object type (Company, Project or Ticket), so it's not an ordinary association between two ordinary object types.
If you want to describe/define such authorization relationships with a class model, you would need to define a meta-class like ObjectType and express that your object types (Company, Project or Ticket) are instances of it.
We're tasked to make a system that will record students daily in and out of the institution premises via student ID, to ensure student safety, and The instructor can also use this system as the student attendance.
Can you help me by checking if this is correct or any improvement is required?
In short
There are some syntactic issues with the associations in your diagram.
Moreover, associations correspond to a structural relationship. Do not create associations, simply because one class uses another at some point in time: for a simple use, a «use» dependency is the most you can do.
More details
Syntactically, this diagram seems correct, except for the label on the association:
Since it's in the middle of the line, we assume it's the association name. But the association name has no visibility.
Since there is a - (private) visibility, we understand that it could be the role of an association end. But It should then be located on the end and not in the middle.
Semantically, from an UML point of view there are some suspicious relationships:
The double composition of Login is probably wrong: composition indicates an exclusive ownership. Your diagram says that a Login occurence is owned either by an Admin or by a Teacher but if it's owned by one, the other cannot be related to it.
Moreover, composition suggest a part-whole relationship and I don't see a login to "be a part of" a teacher or an admin.
The aggregation is not well defined in UML and therfore does not really add value. Some people see it suggesting a part§whole relation with non-exclusive ownership: in this case it would be wrong. Better get rid of it.
The name of the Validates association is confusing as it corresponds to a Login's operation. It might lead to think that the line corresponds to the dynamic invocation of the operation, whereas in reality an association is structural.
But it's difficult to say more in absence of any requirement or analysis context. Based on my domain knowledge:
The 1 to 1 association between Admin and Student must be wrong, since an Admin may enrol 0 users (new admin), or many users
There's a login which is probably used to monitor the in's of the students, but nothing seems to monitor the outs.
Do each student have only one single teacher ?
It's not clear to me if all these associations are a structural relation. For example, we can understand that at a point in time, in a transaction, a teacher validates a login. But should a trace of this validation be kept (i.e. do you expect to be able to later find out all the logins that a teacher has validated? or to find for a given login which teacher did validate it?).
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.
I drives me crazy how many books contradicts themselves.
Class A {} class B {void UseA(A a)} //some say this is an association,
no reference is held but communication is possible
Class A {} class B {A a;} //some say this is
aggregration, a reference is held
But many say that holding a reference is still just an association and for aggregation they use a list - IMHO this is the same, it it still a reference.
I am very confused, I would like to understand the problem.
E.g. here: http://aviadezra.blogspot.cz/2009/05/uml-association-aggregation-composition.html - what is the difference between Strong Association and Aggregation, in both cases the author uses a field to store the reference..
Another example:
This is said to be Association:
And this is said to be Aggregration:
public class Professor {
// ...
}
public class Department {
private List<Professor> professorList;
// ..
}
Again, what is the difference? It is a reference in both cases
This question has been, and will be, asked many times in many different variants, because many people, including many high-profile developers, are confused about the meaning of these terms, which have been defined in the UML. Since the question has been asked many times, it has also been answered many times. See, e.g. this answer. I'll try to summarize the UML definitions.
An association between two classes is not established via a method parameter, but rather via reference properties (class attributes), the range/type of which are the associated classes. If the type of a method parameter is a class, this does not establish an association, but a dependency relationship.
It's essential to understand the logical concept of associations first, before looking at how they are coded. An association between object types classifies relationships between objects of those types. For instance, the association Committee-has-ClubMember-as-chair, which is visualized as a connection line in the class diagram shown below, may classify the relationships FinanceCommittee-has-PeterMiller-as-chair, RecruitmentCommittee-has-SusanSmith-as-chair and AdvisoryCommittee-has-SarahAnderson-as-chair, where the objects PeterMiller, SusanSmith and SarahAnderson are of type ClubMember, and the objects FinanceCommittee, RecruitmentCommittee and AdvisoryCommittee are of type Committee.
An association is always encoded by means of reference properties, the range/type of which is the associated class. For instance, like so
class Committee { ClubMember chair; String name;}
In the UML, aggregation and composition are defined as special forms of associations with the intended meaning of classifying part-whole-relationships. In the case of aggregation, as opposed to composition, the parts of a whole can be shared with other wholes. This is illustrated in the following example of an aggregation, where a course can belong to many degree programs.
The defining characteristic of a composition is to have exclusive (or non-shareable) parts. A composition may come with a life-cycle dependency between the whole and its parts implying that when a whole is destroyed, all of its parts are destroyed with it. However, this only applies to some cases of composition, and not to others, and it is therefore not a defining characteristic. An example of a composition where the parts (components) can be detached from the whole (composite) and therefore survive its destruction, is the following:
See Superstructures 2.1.1:
An association may represent a composite aggregation (i.e., a whole/part relationship). Only binary associations can be aggregations. Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it. Note that a part can (where allowed) be removed from a composite before the composite is deleted, and thus not be deleted as part of the composite. Compositions may be linked in a directed acyclic graph with transitive deletion characteristics; that is, deleting an element in one part of the graph will also result in the deletion of all elements of the subgraph below that element. Composition is represented by the isComposite attribute on the part end of the association being set to true.
Navigability means instances participating in links at runtime (instances of an association) can be accessed efficiently from instances participating in links at the other ends of the association. The precise mechanism by which such access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient. Note that tools operating on UML models are not prevented from navigating associations from non-navigable ends.
Your above examples are on different abstraction levels. Department/Course are concrete coding classes while Department/Professor are at some abstract business level. Though there is no good source (I know) explaining this fact, composition and aggregation are concepts you will use only on business level and almost never at coding level (exception below). When you are at code level you live much better with Association having role names on both sides. Roles themselves are a different(/redundant!) rendering of properties of a class that refer to the opposite class.
Aggregation as a strong binding between classes is used e.g. in database modeling. Here you can delete a master only if the aggregates have all been deleted previously (or vice vera: deleting the master will force deletion of the aggregates). The aggregate can not live on its own. The composition as in your example is (from my POV) a silly construct as it pretends to be some week aggregation. But that's simply nonsense. Then use an association. Only on a business level you can try to model (e.g.) machine parts as composite. On a concrete level a composition is a useless concept.
tl;dr;
If there is a relation between classes show it as simple association. Adding details like roles will aid when discussing domain details. Use of composition/aggregation is encouraged only when modeling on business level and dis-encouraged on code level.
I've written an article about the differences between UML Association vs Aggregation vs Composition based on the actual UML specification rather then interpretations of book authors.
The primary conclusion being that
In short, the Composition is a type of Association with real constraints and impact on development, whereas the Aggregation is purely a functional indication of the nature of the Association with no technical impact.
Navigability is a completely different property and independent of the AggregationKind.
For one thing, UML is a rich language, meaning there is more than one way to describe the same thing. That's one reason you find different ways described in different books (and conflicting answers on SO).
But a key issue is the huge disconnect between UML and source code. How a specific source code construct is represented in UML, and vice versa, is not part of the UML specification at all. To my knowledge, only one language (Java) has an official UML profile, and that's out of date.
So the representation of specific source-language constructs are left to the tool vendors, and therefore differ. If you intend to generate code from your model, you must follow the vendor's conventions. If, conversely, you wish to generate a model from existing source code, you get a model based on those same conventions. But if you transfer that model to a different tool (which is difficult at the best of times) and generate code out of that, you won't end up with the same code.
In language-and-tool-agnostic mode, my take on which relationships to use in which situations can be found here. One point there worth repeating is that I don't use undirected associations in source-code models, precisely because they have no obvious counterpart in actual code. If in the code class A has a reference to class B, and B also has one to A, then I draw two relationships instead.