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).
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.
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.
So I'm working on an assignment for school, where I am to model (using a domain model) a web shop that delivers complete grocery bags to people's homes. (http://www.linasmatkasse.se). I wish I could be more specific here, but this is all I have unfortunately.
I haven't received any use case, but the scenario would be something like, add bag to cart, create account/add info, pay.
This is what I have so far : http://i.imgur.com/BIljBtj.png?1
Are there any redundancies? (I only have to depict the model of the site, unsure how much to include).
Could/Should I add composition between for instance Customer and Account, Cart and OrderLineItem, Order and Cart?
Pretty uncertain about attributes & multiplicites in general. Any feedback or support here is appreciated.
Payment class? Is it needed? Should it have payment methods included?
Should I model human elements like support?
Should I model more of the delivery
Is association between customer and order needed?
Thanks a bunch! Again...
It should be a class diagram. So, such verbs as "has", "contains", should be shown as aggregation, "supplies", "describes", "makes" should appear on associations arrows only if these names are the names of the attribute in the source(for arrow) class. "owns" should be shown as a dot on the end of association. Also put attribute names really on ends of the associations. You can name the whole associations, but that implies, that the association itself, without the instances of the classes, somehow exists. If you want to write comments, they are to be placed on the notes. But normally that words as "supplies", "describes", "makes", "has", "contains", "owns", appear on the Use case diagram. Make it apart from the class diagram, if you want to think on this logic or discuss it with a client or a sales manager you work with.
Composition
That one between Account and Cart you have made very nicely. Thus you cay, that Cart doesn't exist out of its Account and any account has only one cart. So, the composition with multiplicity 1 to 1 is sensible and bears a lot of important info.
The customer as you made it, is useless. You need only Account.
Till now I don't understand the use of OrderLineItem and ItemList. If the use of some classes is not obvious, it is bad - at least put comments there or think, if you really need them.
Payment - yes, it is necessary. As for payment methods, put them in the specific Enumeration class block, name them there as items and connect Payment to PaymentMethods.
No human elements here! You are deep into the IT model, on the border of coding. You really want to do a use case diagram, don't you?
Delivery? Maybe more enumerations for way of delivery and supplier, ClientAddress that is seen from Account, Order. It is for you to decide if you want to cover this or that scope.
ItemDescription should be connected to Item only
All you associations are navigable in both ways. It is senseless. Choose the navigability.
If a class attribute is an instance of another class, put a dot on that another end of association (end owned by classifier).
Supplier connected to Order? Do you want to cover the theme of trade with suppliers, too? Then there should be more classes on that theme. And it could be another component and another class diagram. Or is there a graphic error?
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.