Bulk Register students (extends "Register Student") ---------------------Authorized actors : only R
Individual Register Student (extends "Register Student") ---------------Authorized actors : only R, T, S
Teacher and Student can register themselves but registartion will be accepted only after approval from Registration Officer
Use Case 2 : Register Teacher
Bulk Register Teacher(extends "Register Teacher") ---------------------Authorized actors : only R
Individual Register Teacher(extends "Register Teacher") ---------------Authorized actors : only R, T
Teacher can register themselves but registartion will be accepted only after approval from Registration Officer
I generalized the above 2 Use Cases Register Student and Register Teacher as Register User
Problem How am i supposed to associate actors with the use case diagrams.
which of the following will be correct
a. Show R, T, S associated with Register User
b. Extend Register User -----to----- Register Student and Register Teacher
c. Extend Register Student -----to-----Bulk register Student and Individual Register Student
d. Extend Teacher Student -----to-----Bulk register Teacher and Individual Register Teacher
a. Extend Register User -----to----- Register Student and Register Teacher
b. Extend Register Student -----to-----Bulk register Student and Individual Register Student
c. Extend Teacher Student -----to-----Bulk register Teacher and Individual Register Teacher
d. show R connected to Bulk register Student , Individual Register Student, Bulk register Teacher and Individual Register Teacher
e. show T connected to Individual Register Student and Individual Register Teacher
f. Show S connected to Individual Register Student
Which of the above methods is correct way of representing the scenario ? How do we show authorization in UML Diagrams ?
Either one could be considered "correct" and there most likely could be a variety of other "good" methods as well. Aside, design is a bit different than programming. In programming, there is a "correct" way to spell a keyword for example. However, during the design process, there rarely is a definitive "right" or "wrong" situation. Some designs may be better than others, and some designs may not address the stated requirements. Designs that don't address requirements are "wrong", but there could be many that are "correct."
In UML there is no symbol for indicating the concept of "authorization." However, you could specify authorization using a stereotype or include a note on the diagram.
posted 8 years ago
I understand the we cannot be sharply accurate in design but at the same time we cannot be vague and inconsistant. There could be a serious flip of such a rule. Say i wish to convert this Functional specification into a technical design. The two approaches might result in two different technical designs. According to method I All users interact with the same User Registration Module whereas in the second method there are Two different Modules with which the actors directly interact.
I have a very different point of view while creating designs, I believe just looking at a Use Case diagram can even give us a glimpse into the technical design as well as it gives us ability to have a first look into optimizing application. using Generalization and dependency we can even optimize our application so that we head towards a correct design. Correct me if my view point is incorrect. Becuase with UML deisgn most important is our view point.
posted 8 years ago
Correct, there could be two or more different technical designs. The key concept is to choose the one that addresses all stated requirements. If more than one design can address all of the requirements, then you choose the one that fits in well with your particular situation, e.g. staffing, resources, time, etc.
Keep in mind that while Use Case diagrams may help understand requirements, it usually is text-based narratives which clearly explain requirements.
I was thinking the 2nd method clearly identifies who performs which operation. This gives a person reading the use case diagram a clear picture of who does what. The 1st whereas is vague on identifying the actors with usecases.
I was thinking of another option:
Usecases: Register Student, Register Teacher, Bulk register student, Bulk register teacher.
Actors: Registrar, Student, Teacher
Student -> Register Student
Teacher -> Register Teacher
Registrar -> Bulk Register student, Bulk register teacher.
Bulk Register student <<includes>> Register student
Bulk Register teacher <<includes>> Register teacher.
Use case diagrams are used for understanding the requirements and as well as its elicitation. These may often be shown to the customer so as to get a nod from them that the requirements have been understood by us as they expected. So its often good to keep it simple and devoid of technical jargons.
Ideally Use case diagrams are not directly mapped to the design. They are used as a starting point to understand what the system can do. Requirements when stated in plain text using large sentences are often difficult to understand and may also lead to missing of important information. But when these are pictorially represented, makes things easy to understand.