UML Diagram Analysis

This document provides a detailed analysis of a UML diagram, highlighting its strengths and areas for improvement. It discusses the use cases, actors, and functionality of the system.

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, &

4UML DIAGRAM ANALYSIS
Siahaan, 2018). Once these two aspects of the scenario is clear, half the job is done. A use
case diagram is nothing but a diagram that demonstrates the use of a system and how it
interacts with its various users. The scenario given here clearly mentions the interactions and
actions that is being done by the system. The scenario also mentions the human actors that
are accessing the system. The actors and the use cases are the most important part of the
diagram (Seidl et al., 2015). The next is to determine who performs which interaction and
connect those using lines. The student can also show which use case “includes” another use
case under them and which use case “extends” to another use case (Singh & Sharma, 2015).
In this diagram this has been shown currently in the “subject selection” use case where the
core subjects is compulsory and the electives are optional. This has been shown by using the
“includes” and “extends” connecting lines respectively. Overall if all the relations are
followed properly and proper use case and actor shapes and notations are used, it will
produce a good UML diagram. The UML designed by the student has scope for further
improvement, but the main context and functionality of the system could be easily
understood.

5UML DIAGRAM ANALYSIS
References:
Faitelson, D., & Tyszberowicz, S. (2017, May). UML diagram refinement (focusing on class-
and use case diagrams). In Proceedings of the 39th International Conference on
Software Engineering (pp. 735-745). IEEE Press.
Gelu, P., Sarno, R., & Siahaan, D. (2018). Requirements Association Extraction based on Use
Cases Diagram. Lontar Komputer: Jurnal Ilmiah Teknologi Informasi, 11-19.
Gulia, S., & Choudhury, T. (2016, January). An efficient automated design to generate UML
diagram from Natural Language Specifications. In 2016 6th International
Conference-Cloud System and Big Data Engineering (Confluence) (pp. 641-648).
IEEE.
Kim, Y. G., Hong, H. S., Bae, D. H., & Cha, S. D. (1999). Test cases generation from UML
state diagrams. IEE Proceedings-Software, 146(4), 187-192.
Seidl, M., Scholz, M., Huemer, C., & Kappel, G. (2015). The Use Case Diagram. In UML@
Classroom (pp. 23-47). Springer, Cham.
Singh, A., & Sharma, E. S. (2015). Functional Test Cases Generation Based on Automated
Generated Use Case Diagram. Chandigarh University, International Journal of
Innovative Research in Advanced Engineering (IJIRAE), 2(8).
Singh, M., Sharma, A. K., & Saxena, R. (2016). Formal Transformation of UML Diagram:
Use Case, Class, Sequence Diagram with Z Notation for Representing the Static and
Dynamic Perspectives of System. In Proceedings of International Conference on ICT
for Sustainable Development (pp. 25-38). Springer, Singapore.
Torre, D., Labiche, Y., Genero, M., Baldassarre, M. T., & Elaasar, M. (2018, May). UML
diagram synthesis techniques: a systematic mapping study. In 2018 IEEE/ACM 10th

6UML DIAGRAM ANALYSIS
International Workshop on Modelling in Software Engineering (MiSE) (pp. 33-40).
IEEE.