VIETNAM NATIONAL UNIVERSITY, HANOI INTERNATIONAL SCHOOL GRADUATION PROJECT PROJECT FACILITIES MANAGEMENT SYSTEM Student’s name: Tran Hong Son Hanoi - Year 2023 VIETNAM NATIONAL UNIVERSITY, HANOI INTERNATIONAL SCHOOL GRADUATION PROJECT PROJECT FACILITIES MANAGEMENT SYSTEM TRAN HONG SON sontranhp88@gmail.com STUDENT ID : 19071626 MAJOR INFORMATICS AND COMPUTER ENGINEERING Supervisor: Dr. Nguyen Van Tinh Major: Computer Science and Computer Engineering HA NOI, 11/2023 Statement of Commitment Student Name: Tran Hong Son Contact Number: 0934324860. Email: sontranhp88@gmail.com Class: ICE2019A. I, Tran Hong Son, commit that this project is my individual research work under the guidance of Dr.
Nguyen Van Tinh. The results presented in the project are truthful and the outcome of my own efforts, not copied from any other work. All references in the project – including images, tables, figures, and quoted sentences – are clearly and fully cited in the bibliography. I take full responsibility for any violation of the university's regulations, even if it involves only one copied word.
Ha Noi, day month year Project Author Trần Hồng Sơn iii EXPRESSION OF GRATITUDE I sincerely thank Dr. Nguyen Van Tinh for his dedicated guidance throughout the process of working on the design project, leading to the results we have today. He gave me all the advice and support I needed, as well as all the resources I needed to do my job faster. He also shared with me some tips that I can use.
It was really difficult for me to complete my final assignment without the help of my teacher. During the time of making and completing the project, due to lack of experience, I made many mistakes. As a result, I am looking to receive feedback from professors to help us complete the project and create a solid foundation of knowledge that will help us redefine ourselves in the future. In addition, I would like to sincerely thank my family and friends for enthusiastically contributing and sharing their experiences to help me complete this research.
Once again, I would like to take this opportunity to once again thank all my professors, friends, and family for their unwavering support and dedication to helping me become a better person. iv Table of Contents Commitment. iii Epression of gratitude. iv Table of Contents.
vii List of Tables. viii Formula Catalog. ixi List of Abbreviations. xi Chapter 1 Introduction to the Topic .1 State the problem .2 Objectives and scope of the topic.
2 Chapter 2 Survey and Analyze requirements .1 Current situation survey .1 Overview use case diagram .2 Detailed use case diagram .3 Non-functional requirements. 8 Chapter 3 Technology stack. 10 Chapter 4 Development and Deployment of the application .1 Software architecture selection .3 Detailed package design .2 Layer-by-layer design.3 Developing an application .1 Libraries and tools used .3 Illustrate the main functions. 27 Chapter 5 Prominent solutions and contributions .28 Chapter 6 Conclusion and development direction .31 vi Chapter 1 Introduction to the topic 1.1 State the problem In the past, before technology developed, managing personal or organizational data and physical assets was extremely challenging.
People used to remember everything by hand copying, writing on paper, or exchanging information orally when discussing a matter. This led to many drawbacks such as: - Inconsistent databases resulting in numerous errors. - Discrepancies in data on documents as figures managed at different departmental levels were handwritten by various individuals, poorly stored, leading to potential inaccuracies. - Difficulty in adjusting fluctuations and updating information in a timely manner.
- Tedious data retrieval, especially with a large number of notes. - Challenges in preserving and storing data due to the vulnerability of paper documents to wear and tear, dampness. Because manual note-taking was prevalent, transparency was also compromised, as note writers or others could easily alter content for personal gain, leading to budgetary shortfalls for individuals or organizations.Effective asset management is a crucial factor for organizations, regardless of whether they are businesses, non-profit entities, or government agencies. Efficient asset management brings various benefits to an organization, including optimizing asset utilization, minimizing risks and losses, enhancing transparency in organizational activities, improving responsiveness and customer service, and strengthening cost management and financial performance… 1 1.2 Objectives and scope of the topic To build a system for managing physical assets like that, I have chosen to create a system with two sites catering to two types of users: - Site for Asset Managers - Site for Users, Reporting Asset Status.3 Solution direction The website is built to assist users, as well as non-governmental organizations and businesses, in efficiently managing the assets owned by individuals or enterprises to avoid losses or discrepancies in data recording and ensure uniformity.
The system will maximize the management of the data entered by users, organizing them in sequences for ease of operation and searching, thereby saving time and optimizing tasks. The system will provide information about the assets entered by users, making it easy to add new assets and update existing ones that users wish to manage. Therefore, users looking to manage their assets in the most organized manner can make use of this website. The solution is that I will build a website for the two user roles, accompanied by a server that provides APIs to implement the functions and features mentioned in section 1.4 Project structure Chapter 2: Business Analysis of the Problem, System Use Cases.
Chapter 3: Introduction to the Technologies Used to Build the Project. Chapter 4: Design, Development, and Deployment of the Application. Chapter 5: Prominent Solutions and Contributions. Chapter 6: Conclusion and Development Direction.
2 Chapter 2 Survey and Analyze requirements 2.1 Current situation survey In section 1.1, as presented, the development of a asset management system [1] involves creating two separate sites for different user types. Firstly, for the admin managing physical assets: - Allows the administration of asset categories to facilitate better organization and usage. - Manages physical objects by categories, information, status, quality, etc. - Manages relationships between physical objects, for example, managing a computer may link to objects like keyboards, monitors, CPUs, etc.
- Manages the lifecycle of objects, from acquisition, usage, upgrades, to disposal or when they are no longer in use. - Manages and views reports on damaged or missing assets. - Provides statistical analysis and reporting. For users managing physical assets and reporting status: - Can report on needed but insufficient quantities of specific assets.
- Can report on damaged assets. - Views feedback from the admin regarding reported issues.1 Overview use case diagram A use case diagram provides a high-level overview of the functionality provided by a system from the perspective of its users. It illustrates how users interact with a system and the various scenarios or use cases that the system can handle. Here's a brief overview of the key elements in a use case diagram: Actors: Actors represent external entities (users, systems, or other elements) that interact with the system.
In a use case diagram, actors are depicted as stick figures or blocks. They are the initiators of specific actions within the system. Use Cases: Use cases represent specific functionalities or actions that the system can perform. They describe the system's behavior under various conditions.
Use cases are represented as ellipses on the diagram and are connected to actors with lines. Associations: Lines connecting actors to use cases represent associations, indicating that an actor is involved in the corresponding use case. These lines show how users interact with the system to accomplish specific tasks. System Boundary: The system boundary is a box that encloses all the use cases and actors.
It defines the scope of the system and separates it from the external entities. Include and Extend Relationships: Relationships between use cases can be depicted using include and extend relationships. An "include" relationship indicates that one use case includes the functionality of another. An "extend" relationship signifies optional or extended behavior in certain scenarios.
Generalization: Generalization is represented by an inheritance arrow, showing that one use case or actor inherits the behavior of another. This is useful for showing commonalities and shared functionalities. 4 There are two main actors: the facility manager and the reporter. For the facility manager, the following use cases are applicable: Manage inventory, Manage asset objects, Manage relationships between objects, Lifecycle of asset objects, View and respond to missing or damaged reports, Statistics and report generation.
For the reporter, the following use cases apply: Report missing assets, Report damaged assets.2 Detailed use diagram Use case diagram for decomposed Portfolio Management A Use Case Diagram for decomposed Portfolio Management would provide a visual representation of the various interactions and functionalities involved in managing a portfolio, broken down into specific use cases. In the context of portfolio management, 5 a "decomposed" diagram means breaking down the system into smaller, more manageable parts or use cases. a) Actors Portfolio Manager: The individual responsible for overseeing and managing the portfolio. Investors/Clients: Those who have invested in the portfolio.
b) Use Cases Create Portfolio: The process of creating a new investment portfolio. Update Portfolio: Modifying the portfolio based on market conditions, investor preferences, or other factors. Monitor Portfolio: Keeping track of the portfolio's performance, risks, and returns. Allocate Assets: Deciding on the allocation of assets within the portfolio.
Generate Reports: Creating reports on the portfolio's performance for stakeholders. Risk Management: Identifying and managing risks associated with the portfolio. c) Relationships Association: Connecting actors with the use cases they are involved in. For example, the Portfolio Manager is associated with creating, updating, and monitoring the portfolio.
Inheritance/Generalization: If there are different types of portfolios or portfolio managers, you might represent them through inheritance relationships. d) System Boundary This represents the scope of the portfolio management system. It defines what is inside the system and what is outside. e) Include/Extend Relationships Include: Indicates that one use case includes another.
For example, the "Monitor Portfolio" use case might include the "Generate Reports" use case. Extend: Represents optional behavior that can be added to a base use case. For instance, the "Update Portfolio" use case might extend to include a special case for crisis management. f) Dependencies: Shows dependencies between different use cases, actors, or systems.
6 Decomposition diagram for Asset Management A Decomposition Diagram for Asset Management is a visual representation that breaks down the asset management system into its constituent parts or modules. It provides a high-level view of the components, their relationships, and how they contribute to the overall asset management process. Here are key elements and considerations for creating a Decomposition Diagram for Asset Management: a) System Boundary: Clearly define the boundaries of the asset management system. This boundary outlines what is considered part of the system and what lies outside.
b) Main Components or Modules: Identify the major components or modules that make up the asset management system. These could include: Portfolio Management: Managing a collection of investments and assets. Risk Management: Identifying and mitigating risks associated with assets. Asset Valuation: Determining the value of assets within the portfolio.
7 Client Management: Handling relationships with clients or investors. Reporting and Analytics: Generating reports on asset performance, returns, and other relevant analytics. c) Relationships: Illustrate the relationships between different components. For example, how does information flow between portfolio management and risk management? Are there dependencies between asset valuation and reporting? Interfaces: Specify the interfaces or points of interaction between different components.
This could include data exchange, communication channels, or shared resources. Hierarchy and Layers: If your asset management system has a hierarchical structure or layered architecture, represent this in the decomposition diagram. Show how higher-level modules break down into more detailed sub-modules. Dependencies: Highlight dependencies between different components.
For instance, risk management might depend on accurate and timely data from asset valuation. Include/Extend Relationships: Similar to the Use Case Diagram, you might use relationships like "include" or "extend" to depict how certain functionalities are included in or extend other functionalities. d) Data Flow: Consider incorporating data flow arrows to illustrate how data moves between different modules.