IEEE Research Paper Summary

Design of Tool for Generating UML Analysis Class Diagram

Introduction:
Object-oriented application development involves modelling with various languages, includ ing
Unified Modelling Language (UML). Class diagrams are discovered during the analysis phase,
and creating a complete and accurate diagram is critical. This process can be time-consuming
and lead to complications if not done carefully, particularly in large and complex systems. A
central problem for producing UML analysis class diagram is that the process of generating it
cannot be formalized, but relies on experience, creativity and intuition. As a solution for that,
this project will introduce a tool that assists the users in generating UML analysis class diagram.
This paper describes the design approach used in developing the tool.

About the Author:

1. Faridah Hani Mohamed Salleh, Nazrita Ibrahim and Loo Yim Ling

College of IT, Universiti Tenaga Nasional,

43009 Kajang, Selangor, Malaysia

2. Klaus Bergner, Andreas Rausch, Marc Shiling, Alexander Vilbig

Institut fur Informatik, Technische Universitat at Munchen, Germany

3. Walid Dahhane, Adil Zeaaraoui, EI Hassane Ettifouri, Toumi Bouchentouf

Team SIQL, ENSA Oujda Mohamed First University
Oujda, Morocco.

Title:
1. Design of Tool for Generating UML Analysis Class Diagram

2. Structuring and Refinement of Class Diagrams

3. An Automated Object-Based Approach to Transforming Requirements to Class Diagrams

What are we writing about:
We are writing about a tool that. creates components of an analysis class diagram using an
"Input-Driven Approach." This approach generates the diagram based on the responses given
by users to a set of questions. The users must answer the questions based on a use case diagram
they have already prepared. The answers provided by the users are then used by the tool to
create a UML analysis class diagram. We say this because with the growing complexity of
contemporary systems, the class diagram notation used in current graphical object-oriented
modelling languages will not scale well. The authors suggested the idea of structured interfaces,
a flexible refinement relationship between class diagrams, and the utilisation of attribute,
operation, and relation templates to abstract from implementation specifics in order to address
this issue

Actual concept:
The proposed tool for generating UML analysis class diagrams involves four stages. Firstly,
events flow for each use case of the use case diagram are listed. Then, the <<entity>> class and
its attribute are identified from the events flow. Next, the <<boundary>> class is identified,
followed by the identification of associations between classes. Finally, the refinement process
is performed. The user performs all these stages for each use case in the use case diagram and
answers questions related to each stage. The tool uses the answers provided by the user in the
first four stages to generate the components of the analysis class diagram, while in the fifth
stage, some refinement steps require manual input from the user.

Stage 1: In Stage 1, users list the events flow for each use case to identify and specify necessary
classes. The tool displays guidelines, and users enter the events flow for each use case. Answers
in this stage are not used by the system.

Stage 2: In Stage 2, users identify <<entity>> class and its attributes by answering questions
such as what information is kept by the system and which database is needed for each event
flow listed in Stage 1. This approach helps uncover potentially overlooked classes and guide
users in defining necessary classes based on the use case and its corresponding events flow.
The process of pointing out classes should be done carefully to ensure only necessary classes
are defined.

Stage 3 : Boundary classes are important in every use case, and they should exist for every
actor-use case interaction. They model the interaction between the system and its actors, and
should be related to one actor. Examples of boundary classes include windows, forms, panes,
communication interfaces, and other APIs. Possible candidates of boundary classes can be
identified by asking questions such as whether the system requires printing functions or uses
external devices such as sensors or scanners

Stage 4: The tool design is based on Brown's (2002) approach, which is part of the KRB Seven
Step Method. This approach is used to establish associations between classes, and it involves
identifying the verb and capturing all possible interactions.

i) Discovering the Verb: Verb is discovered by trying to answer this question:

what does a ______do to a ______? Now, say for an example, we have
restaurant manager and report identified as the classes. When these classes are
fitted in the question, full question will sound like this: What does a restaurant
manager do to a report? User may answer: restaurant manager checks the report.
ii) Capturing All Possible Interactions: This factor should be considered to
ensure all interactions or associations between classes are captured. There are a
couple of ways to do this. Matrix is used because it is simple and easy to
implement. The tool will check the existence of association between all the
classes discovered so far.

Requirements, a software system's purpose and the settings in which it is used are both
identified and communicated as part of the engineering (RE) process. The prerequisites
describe the function of a certain system and why it is a good fit for the intended function. So,
the system's target zone has low quality as a result of the loss of precision and informa tio n
throughout the construction phase. Also, when employing the traditional ways (such the
scenario-based approach), this issue becomes crystal clear in practise. To bridge the gap
between RE and other phases, OOADA-RE (Object-oriented Analysis and Design Approach
for Requirements Engineering) has been introduced. [3]

Conclusion:
The project aims to reduce reliance on developer experience and skills for generating class
diagrams by proposing a set of steps and questions to assist users in creating an accurate
analysis class diagram. The proposed tool will enable users to generate analysis class diagrams
without technical knowledge and reduce the time and risk of producing inadequate diagrams.
However, further testing is required to evaluate the possibility of generating analysis class
diagrams automatically using the input-driven approach presented in the paper.