MIS501 - Programming Principles: Analysis of UML Use Case Diagram

This report provides an analysis of UML use case diagrams and their suitability for communicating high-level requirements to programmers. It discusses how use case diagrams capture system requirements, focusing on end-user needs and interactions. The report also explores methods to improve use case diagrams, emphasizing the importance of understanding user expectations and avoiding common misunderstandings in use case modeling. Key areas covered include thinking from the user's perspective, avoiding long use case names, understanding the role of actors, modeling shared use cases, and focusing on the flow of proceedings. The document references several academic sources to support its analysis and recommendations.

Running head: PRINCIPLES OF PROGRAMMING
Name of student
Name of university
Author’s note:

1
UML use case
Suitability of the use-case diagram for communicating high-level
requirements to the programmer
The use of use case diagram is the simple intuitive methods of capturing the system
requirements. The use cases are significantly valuable due to the fact that it keeps the system
development emphasized on the requirements of end user. It also capture the major
requirements of the system in the form, which are readable and easily understandable to any
end user. Particularly, any use case is the narrative description of the goal focussed
interaction among the system while developing along with the external agent. Any use case
could be described the kind of like the script of dialog among both actors. Any use case
mainly captures the dialog among the system and the user in kind of the user activities as well

2
as the system responses. Capturing the requirements in the form of the use cases significantly
effects the delicate shift in the perspectives. The use cases mainly captures the requirements
in the form of the exchanges with any end user. When the capturing of necessities in done
regarding the working of the system, it is easy for the important details to be omitted. When
the describing of requirements is done in the terms of the interactions with the end users, the
details missing becomes significantly obvious.
How to improve the use case diagrams
Commonly there are several misunderstanding regarding the use case modelling or
the use case diagram. The use case diagrams are significantly simple. Use case modelling is a
beneficial practice for the establishment of solid groundwork for the software creators for
developing the software system, which helps in meeting the requirements of the customers.
While notations that are applied in any use case diagram seems significantly modest and does
not provide much thorough, the methods by which the use cases are gathered, elaborated and
organised do effect direction of the software development lifecycle, therefore quality of the
final product of the software. The most appropriate methods by which the use case diagrams
could be improved are focus on thinking from the perspective of the users, avoid any long use
case name, the understanding of the actor as the role and not as any person, the modelling of
shared use case with the relationship, model the situation with the flow of proceedings, not
directly on the diagram. It could be easily understood that there is a requirement of
understanding the expectation of the user for building the software system, which works
accurately and this opinion is specifically significant in the use case modelling. For being
accurate, the use case modelling is the method of modelling that is required by the users. It
could be considered that each use cases in any use case diagram must yield any observable
goal using the interaction of the users with the ultimate system or the software. It is
commonly suggested that the name of the use case should not be very long name that causes

3
confusion among the system developers. The name should be specific and particular name for
each of the use cases. The main reason why there is a requirement of modelling is that the
common people desire to understand any complex software system in any easy and simplified
manner. Due to this, popularity of the UML has offered the several kinds of notations with
each of these representing any particular perspective in the describing any complex software
system.

4
Bibliography
Al-Msie'deen, R., Huchard, M., Seriai, A. D., Urtado, C., & Vauttier, S. (2014). Automatic
documentation of [mined] feature implementations from source code elements and
use-case diagrams with the REVPLINE approach. International Journal of Software
Engineering and Knowledge Engineering, 24(10), 1413-1438.
Mefteh, M., Bouassida, N., & Ben-Abdallah, H. (2014). Feature model extraction from
documented uml use case diagrams. ADA USER, 35(2), 107.
Mefteh, M., Bouassida, N., & Ben-Abdallah, H. (2015, April). Implementation and
evaluation of an approach for extracting feature models from documented uml use
case diagrams. In Proceedings of the 30th Annual ACM Symposium on Applied
Computing (pp. 1602-1609). ACM.
Reggio, G., Leotta, M., Ricca, F., & Clerissi, D. (2014, January). What are the used UML
diagram constructs? A document and tool analysis study covering activity and use
case diagrams. In International Conference on Model-Driven Engineering and
Software Development (pp. 66-83). Springer, Cham.
Saleh, F., & El-Attar, M. (2015). A scientific evaluation of the misuse case diagrams visual
syntax. Information and Software Technology, 66, 73-96.
Salgado, C. E., Machado, R. J., & Maciel, R. S. (2014). Using process-level use case
diagrams to infer the business motivation model with a RUP-based approach.
In Information System Development (pp. 123-134). Springer, Cham.
Scanniello, G., & Erra, U. (2014). Distributed modeling of use case diagrams with a method
based on think-pair-square: Results from two controlled experiments. Journal of
Visual Languages & Computing, 25(4), 494-517.

5
Skersys, T., Danenas, P., & Butleris, R. (2014, May). Approach for Semi-automatic
Extraction of Business Vocabularies and Rules from Use Case Diagrams.
In Enterprise Engineering Working Conference (pp. 182-196). Springer, Cham.