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.
Related
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 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.
Generally in UML, you model roles as opposed to people however if there is a use case to model people (along with their names, contact details, etc), is there a known way of depicting this?
For example do I create a superclass called "Person" and generalize the roles followed by a specialization of a real person?
I took a look at some of your other questions and now I realise I completely misunderstood and you're probably trying to model an organization and the people in it.
ArchiMate is a semantic layer on top of UML that is intended for architecture modelling. Real people get described in the business layer, as actors.
A business actor is defined as an organizational entity capable of (actively) performing behavior.
A business actor performs the behavior assigned to (one or more) business roles. Examples of business actors are humans, departments, and business units. A business actor may be assigned to one or more business roles. The name of a business actor should preferably be a noun.
Now generally the person fills a spot in the organization that in a couple years could be filled by another person. The structure / architecture of the organization would not change and as such the actor can be described by the name of their position, say, "Head of department" rather than by their name and phone number.
Still, I understand that it may be handy to have this sort of information available when you want to contact them.
UML-model-wise, I'd think that the actor Head of Department is a class, realizing a business role that's also a class, and that Joe with phonenumber 12345 is an object of that class.
But practically, I'd think this is too much detail for the level at which you're describing the organization. I'd suggest you stick a UML note on those few actors of key contacts whose names you think are worth mentioning in the diagram. But administrate the rest of them in a system that's more fit for this, like your company's ADS or Contacts in Microsoft Outlook.
I have a few questions regarding use-case diagram:
If my system has register/login use-case for guest, should it be enabled for admin, user (i just wanna clarify, if i have login system, do i assume that admin, user etc. are people who already logged in to system so i skip them with logging thing)?
If my system has a student actor, that is signing for individual seminars/courses, do i have (or am i allowed) to make use-case for ,,taking class'' after singing for them, and should there be relations between those 2
Should my teacher inherit from student actor, since he can browse courses as well? (and so on admin?)
Is my payment setup correct?
Remember that these are roles not people. An admin can be a guest, so long as they behave entirely like a guess, no special functions or rules. However, during log-in the user role could change, become admin. Note you are in some sense missing authenticate user, each use-case that requires security should include it, generally not extend.
Only if it interacts with the system, example, triggers an auto completion or is tracked in some way there of. Relations are not needed generally, associations could help communicate something that is ambiguous, but I am not sure what the would be in this case.
Nope, really then the role is any user could browse courses once they are authenticated. You could have students, admins, and teachers be sub-types of authenticated or associated person, etc.
Depends. Firstly you never pay and sign-up at the same time, so from a user standpoint that is broken. There are other ways in UML to connect this constraint of paying for courses. Process diagram, state diagram, etc. Because payment is really a long running transaction which can be hard to pin down. I would personally show the student and the external payment system interacting with the "payment" use cases.
Remember unless you are generating code most of the time UML is about communication so knowing your audience. Do not be afraid to use comments or constraints, if this is homework, use a constraint and get some real points. Maybe even put a constraint on the sign and pay course use cases.
If you want the admin to be able to log-in then he would have a use case for that. I agree that he most likely won't be registering, so maybe you want to break the register/log-in into two use cases?
You do not have to make a "Take Class" use case. Only make it, if that's how the user will interact with the system. My guess is that he won't be "taking" the class with the system, in which case it won't be a use case of the system.
I would think that you wouldn't want to inherit from student. First of all, from a realistic stand-point, it doesn't make sense. That would mean a teacher is-a student. You could extract that behavior to another parent class, but that might make the hierarchy too large and confusing.
If you are asking whether it is correct to say "sign for course" includes "pay for course," then maybe, it's probably better to use extend.
Another suggestion. The black arrow (usually means "dependency" in UML) you have between Actors and Use Cases, should probably be bi-directional, non-arrowed, line (this is usually called "association") At least that is what the UML standard says.
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).