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?).
Related
I am modeling a course management system with the following requirements:
2 roles: Student can choose course; Administrator can make courses and then make groups for course, based on list of students who chose that course and based on list of tutors for that course.
In one course students can go only in one group, and teacher can teach more groups in one course. But student can go in 1 or more courses.
This diagram is a sketch of a class diagram. There is too much redundancy and I don't know how to solve it. Please help me to model my domain and ignore the mistakes in UML syntax or multiplicitycardinality.
More precisely, how can I make association between students and groups, and tutors and groups without redundancy, because I already have associations with courses?
Let's focus indeed on the domain model:
The direct association between Student and Course corresponds to the student's choice. The choice may or may not be fulfilled. And if it is fulfilled, it's only when the groups are made.
The indirect association between Student and Course via Group corresponds not only to fulfilled choices, but also to practical organisation of courses.
The two paths that exist are not redundant, but the representation of two different realities.
For the tutor, it's similar: the direct association tells what the tutor is able to do, and the indirect one tells what he/she has to do. So the model looks fine in this regard.
In some cases you could simplify (hint: not here)
In some situation a choice/plan can be combined with a fulfilled choice/implementation, by merging associations. For example, if there wasn't your group requirement, you could have only one association class between Student and Course and use a state of your association class to make the difference. But this will not work here, given your requirements.
You could also trick with the requirements. For example, you could have for every course a dummy group that corresponds to students that chose the course and are not assigned to a group. But shortcuts in the design can (and often will) backfire. Here for example, it would add complexity (need to create a dummy group for every course, make a difference between the dummy group and the real groups in almost every activity). Moreover, this trick would constrain your solution. For instance, not having an association class for the choice will prevent from enabling the students to prioritise their courses or providr other elements that facilitate the creation of groups that do not yet exist (e.g. pre-existing skill level).
In summary: your model should primarily aim at addressing the requirements. Premature optimisation is the root of all evil, in modelling as well.
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 am trying to make a use case diagram with the help of my class diagram but the problem is i am here confused that what should i take as actors and what will come and what attributes shall i take and where to use <<extend>> ?
Kindly help. Thank you in advance.
As Thomas pointed out, there is no algorithmic way to go from a class design to a use case. In fact, for a given class diagram, it's not even granted that there is a use case at all (for example, if the classes represent only the relation between business objects and no actors).
However, by analyzing your specific diagram from a human point of view, you can very well infer a class diagram:
1) Identify candidate actors
An actor specifies a role played by a user or any other system that interacts with the subject. Candidates in your diagram are: visitor, admin, and registered user
The classes Movie, Book tickets, Make payment are obviously not representing roles of a user.
2) Identify candidate use cases
A use case defines the interactions of a system and an actor in order to achieve some goal. So let's brainstorm a little bit to find everything that looks like an interaction:
Very explicit candidate use cases: Book tickets (class and method of Registered user), Make payment (class and method of Registered user)
Less explicit candidate use cases or interactions: View movie (relation and method of Registered user), update movie (relation), Add movie record (method of admin), Update movie record (method of admin), delete movie record (method of admin), Confirm registration of visitor (inferred from relation), 'Get registered(method of a user),cancel ticket(and method ofRegistered user),Login(method ofRegistered user),Logout(method ofRegistered user),Update Seats available(method ofBook tickets), confirm transaction (method), refund money of cancelled ticket (method)
Implicit/inferred use cases or interactions : create and maintain admin , create a visitor, register and maintain a registered user account, anything else ?
3) Sort out the use cases
Among all the potential use cases and interaction identified, not all should get the use case status. You have then to find which are use cases and which are just interactions part of the same use case. For example:
update movie catalog would be composed of update movie, Add movie record, Update movie record, delete movie record.
Get registered and Confirm registration of visitor are obviously part of the same use case, because the goal is the same: registering a user.
...
I let you as an execise sort out the rest.
4) Review the actors
After having identified meaningful use cases you may want to review your candidate actors:
Some candidate actors might appear to be in fact only objects that are unrelated to users (it's not the case here, but it could be, for example, if you'd have a Movie producer, which is just an info related to a movie but not a user of the system).
Identify obviously missing actors for important use case that you have identified. Here for example, I first thought it was an internet movie business. But the method Update Seats makes obvious that we are talking of a real theater. So who would get the payment from the user, hand out the ticket, reimburse money in relation with the system ? If it's just the online booking system, we are fine. If the cahs desk operator shall use the system as well, then we should add this actor.
Find out relationship between candidate actors. A registered user was first a visitor. Shall we represent both of them in the diagram or not ?
5) Draw your use case diagram
Now you have all the elements, you can make your use case diagram. But you still have to decide on the level of detail you want to represent. Here a proposal:
You can not create a use case from a class design. Only the other way around. Form follows function, not vice versa.
Your class diagram indicates that you are not yet familiar with class modeling. Your classes Book Ticket and Make Payment sound like use cases rather than proper classes. A class is a container of data and functionality working on those data, whereas a use case is a piece of work that an actor performs with the help of the system.
Giving you the help you need might be too broad for this platform. Study introductory texts on UML modeling to get a feeling for what can be expressed by which type of model. And don't feel obliged to use all elements the language offers. There are plenty of use case models that don't need include and extend relations.
I'm starting to learn UML and have a question about Actor Generalization:
Imagine I'm writing a use case diagram for some kind of application for a College . I've identified there are two Actors; Student and Teacher.
Now, to keep it short, lets say the requirements are fairly simple (and not really important to my question):
A student can search for a class
A student can register for a class
A student can submit a paper
A student can pay his course fees
A Teacher can grade a paper
A student can contact a teacher for one of his classes (e-mail type message, but all managed within the system)
A teacher can contact all students for one of his classes (again all handled by the system).
All jolly good.
Where I get stuck is this:
A Student has a username and password and must login to use the
system
A Teacher has a username and password and must login to use the
system
A Student can reset his password via an online portal
A Teacher can reset his password via on online portal
So my question is ...
How best to handle the common use cases for the system?
On one hand, I could see that both Student and Teacher are a specialized type of User, and the User actor is associated with the common use cases (so A User has a username and password and must login, A user can reset his password via an online portal etc).
On the other hand it seems kind of strange to have Teacher and Student have the same super-actor (correct term?) as they seem to be two very different users of the system. Should I not therefore keep with the two actors (Student and Teacher), and simply make associations between Student to common use cases and Teacher to common use cases?
I've tried both approaches. As I mentioned, the User generalization approach feels off due to the Teacher and Student being very different, but having several of the same use cases for different actors seems a little unoptimized (or redundant, or just funny looking on paper!).
Is there a right or wrong answer on this or is it just down to preference?
One of the most important usages of actor generalization is to "factor out common actor behavior".
The best way to do this is to make the User actor abstract. That way, you don't have to worry about its details and how teacher and student vary so much. "Judicious use of abstract actors simplify your diagram and improve readability".
So I say go with generalization but make the parent actor abstract. Although not doing so is not wrong at all, as you said: no wrong or right.
Quotes are from UML 2 and the Unified Process - section 5.2 - Actor Generalization.
I am trying to draw a conceptual class diagram. In my system, I have one person who can be performing 2 roles. One being "teacher" and other being "student". The same person could be a teacher in one instance and the same person could be a student in another instance. In such a situation, is it good to depict them as 2 separate classes (in my conceptual diagram)?
Please advise.
Thanks
Unless the person is teaching themself, don't get caught up in trying to show relationships that cross a use-case boundary. Validate the links for each scenario separately; just realize that not all connections will be used for every scenario.
People fill roles. Try
Person associated with EducationRole
EducationRole has subclasses of 'Student' and 'Teacher'
Here is a diagram.
They can change the role they play depending on the situation. If you need to show a person teaching themself then create a subclass of EducationRole named 'Autodiadact' which just means self-teacher.
A commenter asked about changing the role using a method and I'd like to include the answer here.
So, yes you could code the ability to change the role in a method but back up and ask the bigger question, why are we changing the role? A teacher is becoming a student or a student is becoming a teacher, either way the model as shown allows a Person to have many EducationRoles (which is what the asterisk denotes) at the same time so there isn't really a need to change the role but support a person with multiple possible roles.
In the conceptual model you are attempting to illustrate relationships between any valid state of the system, not necessarily how the change might be executed (using a method).