UML Diagram Analysis

Running head: UML DIAGRAM ANALYSIS
UML DIAGRAM ANALYSIS
Name of the Student:
Name of the University:
Author Note:

2UML DIAGRAM ANALYSIS
The use case diagram provided by the student is a quite detailed and extensive version of the
required UML. The description mentions the university name, the campuses, the timetable,
courses and classrooms. The description mentions four different actors which include the
program director, the timetabling manager, the students and the teachers. The student here
has made a descriptive UML diagram where he has shown all the necessary actions and
interactions of the actors with the system (Faitelson & Tyszberowicz, 2017). All the functions
of the system has also been well defined. For example, the student has shown the application
login procedure in detail, starting from the login authentication page to the data validation
process. The campus selection procedure has been shown simply. The four campuses shown
here are in Brisbane, Sydney, Melbourne and Adelaide. The UML diagram is quite easy to
understand for a programmer and features the use of well-defined use cases and actors to
demonstrate the functioning of the system. The diagram more or less includes all the aspects
mentioned in the requirement file description. The student has focused on most of the
important points but missed a few.
According to me, the student has missed out on an important use case actor which is
the teachers or teaching staff. The teaching staff is an important aspect of this diagram as they
also interact with this enrollment system and create their timetable. The classes they will take
are given to them by the program director. The timetabling manager allocates the classrooms
to teach the classes. Anything that interacts with system is an actor. The student has also done
some mistakes in joining the actors with the use cases. The login authentication part is to be
done by all the people accessing the enrollment system. The students are not the only one
interacting with the system. The UML diagram also mentions a “Receive COE” use case
which I feel is not needed for the system. Torrents University is shown as a human actor
which it is not. The only human actors that can be shown are the students, teachers,
timetabling manager and the program director. The connections and actions between each

3UML DIAGRAM ANALYSIS
actor is not so clear in this diagram. Individual connections can be made from each actor to
show their functions (Gulia & Choudhury, 2016). For example, the timetabling manager
would be able to allocate classrooms to students and teachers. So the use cases “Allocate
classes to staff” and “Allocate classroom to classes” should be shown separately connected to
the timetabling manager and the program director respectively. The program director’s job is
to allocate the classes to the teaching staff. The “extends” and “includes” relations also needs
more clarity for better understanding. The use case diagram should have also included the
opening classes use case and the schedule classes use cases. The first use case is for the
program director and the second use case is for the timetabling manager. This two functions
are critical to the functioning of the enrollment system. The subject selection use case is well
designed but the slot selection use case could be improved. The students have been shown as
customers in this UML diagram and are divided into two groups: guest and current students.
The guest actors should be renamed to “future students” as mentioned in the description. The
subjects are divided properly into core and elective as mentioned in the requirements. Some
of the unnecessary use case I feel is the campus selection use case and the university name
human actor. Thus the use case diagram can be improved further by eliminating unnecessary
use cases, properly joining the actors with the use cases to increase function relationship
clarity and by properly defining and adding missing human actors in the use case diagram
(Torre et al., 2018). The diagram can be further enhanced by adding missing functionalities
and interactions of the system in the form of use cases. All in all, any type of interaction that
can be possible with the system is a possible use case.
The best way to read and make a use case diagram is to first read the description and
given scenario thoroughly (Kim et al., 1999). Based on the information gathered, it is very
important to correctly identify the main interactions or functions that the system is
performing and for whom or by whom the action is being performed (Gelu, Sarno, &