Represents Software Requirement and Specification for Code to class diagram,one of cool implementation of Reverese Engineering

1. 1
SOFTWARE REQUIREMENTS
SPECIFICATION (SRS)
for
SOURCE CODE TO CLASS
DIAGRAM CONVERTOR
Prese ted By: SSG _G Prese ted To:
• Sa hi Ku ar Shar a Kuldeep Ku ar
H P Assista t Professor
• A hi av Si gh Garia
H P
• Na da Maj udar
H P

2. 2
CONTENTS
1. Introduction
1.1 Purpose and Scope
1.2 Document Conventions
1.3 Documents, Acronyms and Abbreviations
1.4 Intended Audience and Reading Suggestions
1.5 References
2. Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 Operating Environment
2.4 User Documentation
2.5 General Constraints, Assumptions and Dependencies
3. Specific Requirements
3.1 External Interface Requirements
3.2 Functional Requirements
3.3 Non Functional Requirements
3.4 Design and Implementation Constraints
3.5 Other Requirements
4. To Be Determined List

3. 3
1. INTRODUCTION
1.1 Purpose and Scope
UML (Unified Modeling Language) class diagrams are commonly used in
industry for forward engineering. Despite the clear advantages of
having UML class diagrams for the maintenance and evolution of a
system (e.g., ability to reason about the design of a system at a high-
level), these artifacts are rarely maintained or may no longer exist.
Several reasons exist for the lack of adoption by industry for
maintenance/evolution activities. Among these are, the manual
recovery of UML class diagrams is a timely and costly operation.
Additionally, most automatic reverse-engineering tools perform poorly,
focusing on producing simple class diagrams while failing to properly
represent design abstractions. It has also been noted that if tools fail to
disclose the internal processes for producing the UML, then this can
lead to results that do not meet end-users expectations.
Our project addresses these problems by defining a set of accurate
mappings for reverse-engineering of UML class diagrams from Java
source code.This project is useful for all those developers who are
building applications in Java because we are converting Java source file
to UML Class Diagram. Through this application, they can easily view
the class diagram and relationships among them. This project aims at
providing clear and neat graphical view of diagrams through Java API.
There are few softwares available but do not provide satisfactory
results either in terms of graphical viewing or relationships among the
classes which motivated us to take this project. This project is beneficial
to naive as well as professional people who write applications in Java
because visualization of classes and its relationship is the heart of
Object-Oriented Programming.

4. 4
1.2 Definitions, Acronyms and Abbreviations
Table 1-Definitions
Term Definition
User Someone who gives java source code as input to our
software.
Stakeholder Any person who has interaction with the system who is
not a developer.
OS Operating System
AWT Abstract Window Toolkit
JDK Java Development Kit
JVM Java Virtual Machine
JRE Java Runtime Environment
UML Unified Modelling Language
GUI Graphical User Interface
IDE Integrated Development Environment
Intellij Idea Java IDE
Java API An application programming interface (API), in the
context of Java, is a collection of prewritten packages,
classes, and interfaces with their respective methods,
fields and constructors.

5. 5
1.3 Intended Audience and Reading Suggestions
This document is intended for Users or System Customers, Developers,
Project Manager and Testers. Users specify requirements and read it to
check that they meet their needs. Developers read it to understand
what system is to be developed. Manager uses it to plan system
development process and Tester uses it to develop validation tests for
the system.
The remainder of this document includes three chapters. The second
one provides an overview of the system functionality. It introduces
different types of stakeholders and their interaction with the system. It
also describes the environment in which the software will operate,
including the hardware platform, operating system and versions, and
any other software components or applications with which it must
peacefully coexist. Further, the chapter also mentions the system
constraints and assumptions about the product. This chapter is quite
useful for users of this system
The third chapter provides the requirements specification in a detailed
manner and a description of different system interfaces. This chapter is
primarily written for developers as it describes functionality details of
the software in technical terms and also for users as it has use cases.
The final chapter contains a numbered list of the to be determined
references that remain in the SRS so that they can be tracked to
closure. It also lists any open questions or things which still need to be
done to the SRS, but haven’t been addressed yet.

6. 6
1.4 References
[1] E. Korshunova, M.Petkovic, V.D Brand, M.R. Mousavi, "Reverse
Engineering of UML Class, Sequence, and Activity Diagrams from C++
Source Code", Proc. of WCRE, Benevento, Italy, Oct. 2006
[2] M. John Decker, K..Swartz, M. L. Collard, J. I. Maletic, A Tool for
Efficiently Reverse Engineering Accurate UML Class Diagrams , Conf.,
Raleigh, NC, USA, Oct. 2016
[3] A.Jain, S.Soner, A.Holkar, Reverse engineering: Extracting
information from C++ code , Conf., San Juan, PR, Oct 2010
[4] P.Tonella, A.Potrich, Reverse engineering of the UML class diagram
from C++ code in presence of weakly typed containers , Conf.,
Florence,Italy, Nov 2001
[5] A.Sutton, J. I. Maletic, Recovering UML class models from C++: A
detailed explanation , Conf., MA USA, March 2007
[6] R. Kollmann, P.Selonen, E. Stroulia, A. Zündorf, A Study on the
Current State of the Art in Tool-Supported UML-Based Static Reverse
Engineering , Conf., USA, Nov 2002

7. 7
2. OVERALL DESCRIPTION
2.1 Product Perspective
During software evolution, programmers devote most of their effort to
the understanding of the structure and behaviour of the system. For
object oriented code, this might be particularly hard, when multiple,
scattered objects contribute to the same function. Design views offer
an invaluable help, but they are often not aligned with the code. As a
result, proper application might be a requirement for the developers to
study and understand various aspects of code they are implementing.
This product is a follow-on member of a product family (Source Code to
Class Diagram) with self-contained features as well. Relationship among
the Classes and Packages, Interfaces will also be visualized.
There are basically 3 components in our project. First component deals
with Parsing or Extraction where user code is analysed and using
algorithms proper results are generated. Second component mainly
deals with either storing information in file or database depending
upon its feasibility. Third is drawing of information whether names,
fields, methods or their relationships among them on the screen using
graphics library provided by Java.

8. 8
Diagram showing Components and Interconnections
2.2 Product Functions
The main aim of this application is to give class diagram respective of
the source code. So user will be the only actor in this scenario. User will
be provided functionalities related to inputs. User will be given option
of selecting single or multiple source code files and then the user can
proceed further. After that the user will be able to view desired class
diagram. User can identify the classes and other components which are
of concern. An option for saving the class diagram will be provided. The
user will then have to decide whether to close the application or get
class diagram of other files.

9. 9
2.3 Operating Environment
Main benefit of Java based applications is its ability to run in any
platform (platform-independence). Similarly, Java Swings (AWT has
some platform dependence) applications are also not OS specific. This
project is developed with JDK v1.8 installed in Windows 10 O.S. This
project will work in every Operating System in which Java Runtime
Environment is being set up by the programmers i.e. the users of this
project.
2.4 User Documents
User Manual and Video Tutorial will be delivered along with the
software.
2.5 General Constraints, Assumptions and
Dependencies
Only necessity as well as constraint of our project is to have JVM (JDK
V1.8 specifically because some methods or classes might have different
features as every JDK might change some specifications) installed on
system which will be present as programmers are expected(assumed)
to build applications which is not possible in absence of Java Runtime
Environment(JRE).
The project is also dependent on Graphics library whether library is
capable of drawing neat diagrams of classes and its relationship. If
inbuilt java graphics library is not producing satisfactory results of
drawing, then third-party graphics library will be used by us.

10. 10
3. SPECIFIC REQUIREMENTS
3.1 External Interface Requirements
3.1.1 User Interface
Following Standards are followed in our project
(i) Button
Style – Bold
Size - 12
Border- Black
Background Color - Sky Blue
(ii) Error Message
Style – Bold
Button – OK feature
SIZE -12

11. 11
Splash Screen
Splash screen appears when the user runs application.

12. 12
Main Screen (File Chooser)
Firstly the user will select either single file or multiple files option.
After selection, the user will upload Java files and then these Java files
will be parsed. Parsed information will be stored in database and then
this information will be retrieved when Class diagram is built.

13. 13
Error Message Dialog Box
Error message in above figure will be displayed when user selects files
of incorrect format.

14. 14
Sample Output Screen
The Class Diagram corresponding to Java source code will be displayed
on the output screen given above. User can also save the class diagram
by clicking on Save button.
3.1.2 Software Interface
This is project is implemented in Windows 10 and JDK 1.8v .Database
used is MySQL Database in which Classes, fields and methods are
stored. Connection between application and MySQL is done through
jdbc-mysql api. As soon as parsing of file is performed, connection
between application and database is established. Complete data of
class, fields and methods will be stored in database with Tables like

15. 15
Class (containing complete classes), Methods (containing complete
methods of classes), Fields(containing complete fields of classes).Class
table will be referenced to Fields and Methods table.
3.2 Functional Requirements
This section shows the requirements that specify all the functional
actions.
Functional Requirement 1:
ID: FR1
Purpose: Run Application
Requirements: User system will require Java Virtual Machine (JVM).
Output: When the user will run this application a start screen will be
displayed and then the user will be redirected to the home screen. This
entire application will be implemented in Java Swing’s API.
Dependency: --
Functional Requirement 2:
ID: FR2
Purpose: Select Input Mode
Input: There will be 2 options for the user to select input
1. Single File
2. Multiple Files
Output: As the user will select one option the option for Browse file/s
will be enabled.
Dependency: FR1
Use Case:

16. 16
Functional Requirement 3:
ID : FR3
Purpose: Upload File
Input: There will be a Browse Files option which will let the user select
the files from any location in their system. Each file should be of .java
format which is the required source file to be given as input.
Output: The list of files selected will be shown and the option for
proceeding further to view the class diagram will be enabled.
Dependency: FR2
Use Case:

17. 17
Functional Requirement 4:
ID: FR4
Purpose: Click to View Diagram
Input: Click the button enabled after uploading of files.
Output: As an output the user will be shown the desired class diagram
in an image panel. This step may take time because entire process of
creating class diagram and displaying the image panel is included in this
step.
Dependency: FR3
Functional Requirement 5:
ID: FR5
Purpose: Save Class Diagram
Input: Along with the class diagram one option to save the class
diagram will be provided so the user can save and view it whenever
desired. The user can save the file to desirable location.
Output: As the user will select the location of the file, the file will be
saved to his/her system.
Dependency: FR4
Use Case:

18. 18
Functional Requirement 6 :
ID: FR6
Purpose: Proceed further options
Input: There will be option for proceeding further which will include 2
buttons.
1. Go to Home Page.
2. Close the Application.
Output: The output will be according to selected button. If user selects
go to Home Page the he or she will be redirected to the home page.
Otherwise user may close the application.
Dependency: FR4
Use Case:

19. 19
3.3 Non-Functional Requirements
User Interface Requirements
As this application has partial requirement of a very decorative User
Interface the UI is to be kept simple, user-friendly, intuitive and easy-
to-use.
The UI will not include any irrelevant information and will be decent
according to the project.
Performance Requirements
Performance requirement plays important role especially where real
time is considered. The class diagram should be created and displayed
within approximately 20 seconds. The diagram takes time according to
number of files uploaded.
Thus efficient working will be ensured. There will be no interoperability
overheads because this application will not be linking to any other
application.

20. 20
Availability and Reliability
This system does not require any User Login so anyone can use this and
it will be available on multiple platforms. User can save the class
diagram whenever required. The class diagrams delivered as output will
be reliable as efficient algorithms and graphics libraries will be used.
Error Handling
This system shall prevent loss of the information provided by user in
any case of errors.
3.4 Design and Implementation Constraints
The application shall be implemented in a standard IDE like IntelliJ Idea.
The GUI shall be created using Java Swing’s API. No external tool for
drawing class diagrams will be used. Only an efficient graphics library
compatible with Java shall be used. The prime constraint in this
application will be inability to handle large number of classes efficiently.
As no separate tool for drawing class diagram is used there may be
overlapping and inefficiency when more number of classes are there.
Complex relationships among classes also may not be handled because
it requires very deep association recognition between classes. Any
system which uses this application should have a Java Virtual Machine
(JVM) installed to run this application.
3.5 Other Requirements
Licensing Requirement
Not Applicable
Reusability

21. 21
This application shall be reused any number of times on any platform
and any system having JVM installed on that.
Database Requirements
Information obtained from parsing of source file will be stored in
database. When class diagrams are to be drawn the data from tables
will be retrieved as required. Data will include Class names, interface
names, method names and implements relation as well as extends
relation.
4. TO BE DETERMINED
There will be a need for third party graphics tool if the graphics libraries
of Java will not give satisfactory results.