FINANCIAL MANAGEMENT SYSTEM

A Case Report for AI 365(PCC)

COLLEGE OF TECHNOLOGY AND ENGINEERING

MPUAT, UDAIPUR
SOFTWARE ENGINEERING
(AI-365)
LAB RECORDS
SUBMITTED TO : Mrs. Shefali Jain
SUBMITTED BY : Moksh Mori
ENROLLMENT NO : 2021/CTAE/226
ROLL NO : 41
DEPARTMENT : Ar�ficial Intelligence
BATCH : B
SEMESTER : Sixth
CLASS : B. Tech III Year

1|Page
 TABLE OF CONTENT

1. Abstract
2. Introduc�on
3. Problem Statement
4. So�ware Requirement Specifica�on
5. Lucid Chart Tool
6. System Design

• Data Flow Diagram

• Use-Case Diagram
• Ac�vity Diagram
• Class Diagram
• Sequence Diagram
• Component Diagram
• Deployment Diagram

2|Page
ABSTRACT:
This theore�cal project explores the development of a financial
management system so�ware, focusing on its design and implementa�on
alongside the integra�on of En�ty-Rela�onship (ER) diagrams. In response
to the growing complexity of financial opera�ons, the study addresses the
need for efficient and user-friendly so�ware solu�ons to streamline
management processes. Through a comprehensive literature review,
exis�ng financial management systems are evaluated, highligh�ng both
their strengths and limita�ons. Drawing upon established theories and
concepts in financial management, coupled with modern so�ware design
principles, the project proposes a novel system architecture and user
interface tailored to meet the evolving needs of financial professionals. Key
features include robust data management func�onali�es and intui�ve user
interfaces, all informed by ER diagrams to ensure op�mal database design
and performance. The project's methodology encompasses rigorous
requirements analysis, itera�ve design itera�ons, and thorough tes�ng
procedures to ensure the so�ware's reliability and effec�veness. Evalua�on
of the system's performance reveals promising results, indica�ng its
poten�al to enhance financial management prac�ces across various
industries. By contribu�ng a theore�cal framework and prac�cal insights,
this project aims to advance the field of financial management systems and
inform future research and development endeavours.

3|Page
INTRODUCTION:
The so�ware is cra�ed to revolu�onize financial management by
streamlining processes, enhancing efficiency, and mi�ga�ng risks. Through
automa�on and advanced analy�cs, it empowers users to make informed
decisions swi�ly, leveraging centralized data management for accuracy and
compliance. Its scalability ensures adaptability to evolving business needs,
ushering in a new era of agility and strategic foresight in financial opera�ons.

PROBLEM STATEMENT:
Despite advancements in technology, many organiza�ons s�ll grapple
with outdated and inefficient financial management processes. Manual data
entry, disparate systems, and lack of analy�cal capabili�es hinder decision-
making, increase opera�onal costs, and pose compliance risks. There is a
pressing need for a comprehensive financial management so�ware solu�on
that automates tasks, centralizes data, provides advanced analy�cs, ensures
compliance, and adapts to evolving business needs. This so�ware aims to
address these challenges and empower organiza�ons to achieve greater
efficiency, accuracy, and agility in their financial opera�ons.

4|Page
SOFTWARE REQUIRMENT SYSTEM:
CONTENT:

1. Introduc�on
• Purpose
• Scope
• Overview

2. General Descrip�on
• Product Perspec�ve
• Product Func�ons
• User Characteris�cs
• General Constraints

3. Specific Requirements
• Func�onal Requirements
• Performance Requirements
• Non-Func�onal Requirements
• Design Constraints

5|Page
Introduc�on:
• Purpose
The purpose of this theore�cal project is to address the
aforemen�oned challenges and contribute to the advancement of financial
management systems through the development of a comprehensive
so�ware solu�on. By leveraging the latest advancements in technology and
drawing upon established theories and concepts in financial management,
this project aims to design a so�ware system that not only meets the
complex needs of modern financial management but also enhances user
experience and overall efficiency. Through a systema�c approach to
so�ware development and rigorous tes�ng methodologies, the project
seeks to create a robust and reliable system that can adapt to the evolving
demands of the financial industry.

• Scope
The scope of this theore�cal project encompasses the en�re lifecycle
of so�ware development, from requirements analysis to implementa�on
and evalua�on. Specifically, the project will involve conduc�ng a thorough
literature review to understand the current state of financial management
systems and iden�fy areas for improvement. Subsequently, the project will
focus on the design and architecture of the so�ware, including the
integra�on of En�ty-Rela�onship (ER) diagrams to op�mize database
design. The implementa�on phase will involve coding, tes�ng, and
refinement of the so�ware, culmina�ng in a comprehensive evalua�on of
its performance and usability. Addi�onally, the project will explore the
broader implica�ons of the developed so�ware for financial management
prac�ces and provide recommenda�ons for future research and
development endeavours.

6|Page
 • Overview
The evolu�on of technology has profoundly transformed the
landscape of financial management, ushering in an era where organiza�ons
rely heavily on so�ware solu�ons to streamline their financial opera�ons.
From small businesses to mul�na�onal corpora�ons, the demand for
efficient and user-friendly financial management systems has never been
greater. Tradi�onal methods of financial management are increasingly being
replaced by digital solu�ons that offer enhanced capabili�es in data
analysis, forecas�ng, and decision-making. However, amidst this digital
revolu�on, challenges such as data security, interoperability, and
adaptability persist, highligh�ng the need for innova�ve approaches to
so�ware design and implementa�on in the realm of financial management.

General Descrip�on:
• Product Perspec�ve
The financial management system operates within a broader
technological ecosystem, interac�ng with various external systems and
stakeholders. It interfaces with exis�ng enterprise systems such as
accoun�ng so�ware, ERP systems, and CRM pla�orms to exchange data and
facilitate seamless integra�on of financial processes. Addi�onally, the
system may interact with external financial ins�tu�ons and regulatory
bodies for transac�ons, compliance repor�ng, and regulatory filings. Its
perspec�ve encompasses both internal organiza�onal needs and external
industry standards, ensuring compa�bility, interoperability, and compliance
with relevant frameworks and regula�ons.

• Product Func�ons
The financial management system encompasses a wide array of
func�onali�es aimed at streamlining financial processes and empowering
users with insigh�ul decision-making tools. One of its primary func�ons is
the management of financial data, which involves capturing, storing, and
7|Page
organizing data from various sources to ensure accuracy and integrity
throughout the system. This data serves as the founda�on for other key
func�ons, such as budge�ng and forecas�ng. Users can leverage the system
to create and manage budgets effec�vely, as well as forecast future financial
performance based on historical data and assump�ons.

In addi�on to budge�ng and forecas�ng, the system facilitates the

processing of financial transac�ons, including invoicing, payments, and
expense tracking. By automa�ng these processes, the system ensures �mely
and accurate recording of transac�ons, reducing manual effort and
minimizing errors. Moreover, the system provides robust repor�ng and
analysis capabili�es, allowing users to generate customizable reports and
dashboards to analyse financial performance, monitor key metrics, and
track trends. This enables stakeholders to make informed decisions and
drive business growth effec�vely.

Compliance management is another cri�cal func�on of the financial

management system. It helps organiza�ons ensure compliance with
regulatory requirements and internal policies through features such as audit
trails, controls, and automated compliance checks. By maintaining
compliance, organiza�ons mi�gate risks and uphold their reputa�on in the
market. Addi�onally, the system supports risk management efforts by
iden�fying, assessing, and mi�ga�ng financial risks through risk analysis,
scenario modelling, and proac�ve risk management strategies.

Furthermore, the system fosters collabora�on and communica�on

among team members by facilita�ng document sharing, workflow
management, and communica�on tools. This promotes transparency,
accountability, and efficiency within the organiza�on. Finally, the system
offers seamless integra�on with other enterprise systems and external data
sources to facilitate data exchange and streamline processes. Overall, these
func�ons collec�vely enable organiza�ons to op�mize their financial
opera�ons, enhance decision-making capabili�es, and achieve their
strategic objec�ves in today's dynamic business environment
8|Page
• User Characteris�cs
User Role Exper�se Responsibili�es Needs Proficiency
Financial Finance & Manage financial Advanced High
Managers & Accounting operations, track functionalities:
Accountants Principles budgets, generate budgeting,
reports transaction
processing,
reporting
Executives & Strategic Gain insights into High-level Varies
Senior Decision- financial dashboards,
Management Making performance, make summarized
strategic decisions reports,
strategic
analysis tools
Finance Team Basic to Support financial User-friendly Basic to
Members Intermediate operations, data interfaces, Intermediate
Finance Skills entry, reconciliation customizable
workflows,
help tools
Administrators System Configure system Administrative Advanced
& IT Staff Administration settings, manage features for
Skills accounts, ensure configuration,
security user
management
External Regulatory Conduct audits, Access to Familiar with
Auditors & Compliance & review financial financial data, Auditing
Regulators Auditing data, ensure audit trails, Procedures,
compliance compliance Regulations
reports
Stakeholders Diverse Review financial Summarized Varies
& Decision Business performance, reports, key
Makers Backgrounds provide feedback, performance
make decisions indicators,
customizable
dashboards

9|Page
• General Constraints
Budgetary Constraints:
The financial management system development must operate within
predefined budgetary limits. This necessitates priori�zing features, cost-
effec�ve solu�ons, and efficient resource alloca�on to ensure project
viability while adhering to financial constraints.

Time Constraints:
Adherence to project �melines is crucial, requiring �mely comple�on
of development, tes�ng, and deployment phases. Any delays could disrupt
project schedules, incur addi�onal costs, and poten�ally impact the
system's effec�veness upon implementa�on.

Resource Constraints:
Limited availability of human resources, exper�se, and technology
infrastructure may pose challenges. Effec�ve resource management and
alloca�on are essen�al to overcome such constraints, ensuring op�mal
u�liza�on and project success.

Technical Constraints:
Compa�bility with exis�ng infrastructure, including hardware,
so�ware, and network capabili�es, must be considered. Compliance with
industry standards and protocols and integra�on with legacy systems are
vital to ensure seamless opera�on within technical constraints.

Regulatory Constraints:
Compliance with regulatory requirements and industry standards is
paramount. The system must adhere to applicable laws, regula�ons, and
best prac�ces to ensure data security, privacy, and legal compliance.

Security Constraints:
Protec�on of sensi�ve financial data from unauthorized access and
cyber threats is cri�cal. Implementa�on of robust security measures,

10 | P a g e
 including encryp�on, access controls, and regular security audits, is
essen�al to mi�gate security risks effec�vely.

Scalability Constraints:
The system must be capable of scaling to accommodate growing data
volumes, user popula�ons, and organiza�onal needs. Scalability
considera�ons should be integrated into the system architecture and design
to ensure long-term viability and flexibility.

Specific Requirement:
• Func�onal Requirement
The Financial Management System (FMS) aims to revolu�onize
financial processes within organiza�ons by offering a comprehensive suite
of func�onali�es tailored to meet the diverse needs of users across various
departments.

The system begins by ensuring secure access, requiring user

authen�ca�on before accessing any func�onali�es. Once authen�cated,
users can leverage the system to perform a mul�tude of tasks related to
financial data management, analysis, and repor�ng.

Key func�onali�es include the ability to capture, store, and manage

financial data from various sources, ensuring accuracy and integrity
throughout the system. This includes maintaining records of transac�ons,
budgets, forecasts, and other financial informa�on essen�al for decision-
making.

The system facilitates transac�on processing tasks such as invoicing,

payments, and expense tracking, streamlining financial opera�ons and
ensuring �mely and accurate recording of transac�ons. Addi�onally, robust

11 | P a g e
 repor�ng features enable users to generate customizable reports and
dashboards, providing insights into financial performance, trends, and
metrics.

Advanced analy�cal capabili�es are integrated into the system,

enabling users to perform tasks such as budge�ng, forecas�ng, and financial
planning. This includes the ability to analyse historical data, iden�fy
paterns, and make informed projec�ons to support strategic decision-
making.

Compliance management features ensure adherence to regulatory

requirements and internal policies, including audit trails, controls, and
automated compliance checks. Furthermore, risk management
func�onali�es enable users to iden�fy, assess, and mi�gate financial risks
through risk analysis, scenario modelling, and proac�ve risk management
strategies.

The system also supports collabora�on and communica�on among

team members, providing features such as document sharing, workflow
management, and communica�on tools. This fosters transparency,
accountability, and efficiency within the organiza�on, enhancing teamwork
and produc�vity.

Integra�on capabili�es enable seamless data exchange with external

systems and data sources, facilita�ng interoperability and streamlining
processes across the organiza�on. This ensures that the system remains
adaptable to evolving business needs and technological advancements,
maintaining its relevance and effec�veness over �me.

• Financial Managers and Accountants:

12 | P a g e
 Financial managers and accountants play a crucial role in overseeing
financial opera�ons and ensuring compliance with regulatory standards.
Their func�onal requirements include:
Data Management:
Financial managers and accountants require the ability to capture,
store, and manage financial data accurately and securely. This includes
recording transac�ons, upda�ng ledger entries, and maintaining financial
records in accordance with accoun�ng principles.
Repor�ng and Analysis:
They need robust repor�ng and analysis tools to generate financial
reports, analyse performance metrics, and track key indicators. This includes
features such as customizable dashboards, trend analysis, and variance
repor�ng to iden�fy areas for improvement and make informed decisions.
Budge�ng and Forecas�ng:
Financial managers require tools for budge�ng, forecas�ng, and
financial planning to set financial goals, allocate resources, and monitor
budget performance over �me. This includes features such as budget
templates, forecas�ng models, and scenario analysis tools.
Compliance and Audit:
They need features to ensure compliance with regulatory
requirements and facilitate audit processes. This includes maintaining audit
trails, implemen�ng internal controls, and genera�ng compliance reports to
demonstrate adherence to regulatory standards.

• Execu�ves and Senior Management:

Execu�ves and senior management are responsible for strategic decision-
making and oversight of financial performance. Their func�onal
requirements include:
13 | P a g e
 Strategic Planning:
Execu�ves require tools for strategic planning, goal se�ng, and
performance monitoring to align financial objec�ves with organiza�onal
goals. This includes features such as strategic dashboards, KPI tracking, and
performance scorecards to measure progress and track outcomes.
Financial Analysis:
They need advanced analy�cal tools for financial analysis, scenario
modelling, and trend forecas�ng to assess the financial health of the
organiza�on and iden�fy opportuni�es for growth. This includes features
such as financial modelling, sensi�vity analysis, and predic�ve analy�cs to
support strategic decision-making.
Risk Management:
Execu�ves require features to iden�fy, assess, and mi�gate financial
risks to the organiza�on. This includes risk assessment tools, risk registers,
and risk mi�ga�on strategies to manage risks effec�vely and protect
organiza�onal assets.
Communica�on and Collabora�on:
They need communica�on and collabora�on tools to facilitate
collabora�on among team members and stakeholders. This includes
features such as document sharing, messaging, and collabora�on portals to
streamline communica�on and improve decision-making.

• Finance Team Members:

Finance team members support financial managers and accountants in day-
to-day financial opera�ons. Their func�onal requirements include:
Transac�on Processing:
Finance team members require tools for transac�on processing,
including invoicing, payments, and expense tracking. This includes features
14 | P a g e
 such as invoice genera�on, payment processing, and reconcilia�on to
ensure accurate and �mely recording of financial transac�ons.
Data Entry and Valida�on:
They need features for data entry and valida�on to ensure the
accuracy and integrity of financial data. This includes data entry forms, data
valida�on rules, and error checking mechanisms to prevent data entry
errors and inconsistencies.
Reconcilia�on and Repor�ng:
Finance team members require tools for bank reconcilia�on, account
reconcilia�on, and financial repor�ng. This includes features such as
reconcilia�on workflows, automated repor�ng, and variance analysis to
reconcile discrepancies and generate accurate financial reports.
Compliance and Documenta�on:
They need features to ensure compliance with regulatory
requirements and maintain documenta�on for audit purposes. This includes
compliance checklists, audit trails, and document management tools to
track compliance ac�vi�es and document evidence of compliance.

• Administrators and IT Staff:

Administrators and IT staff are responsible for system administra�on and
maintenance. Their func�onal requirements include:
System Configura�on:
Administrators require tools for system configura�on, including user
management, role-based access control, and system se�ngs. This includes
features such as user provisioning, permission management, and system
configura�on wizards to customize the system according to organiza�onal
needs.

15 | P a g e
 System Monitoring and Performance:
They need features for system monitoring and performance
management to ensure the stability, reliability, and scalability of the system.
This includes monitoring dashboards, performance metrics, and aler�ng
mechanisms to iden�fy and address system issues proac�vely.
Security and Compliance:
Administrators require features to enforce security policies, manage
access controls, and ensure compliance with regulatory standards. This
includes features such as data encryp�on, access controls, and audit logging
to protect sensi�ve informa�on and maintain regulatory compliance.
Integra�on and Data Management:
They need tools for data integra�on, migra�on, and management to
facilitate data exchange with external systems and ensure data integrity. This
includes features such as data import/export u�li�es, API integra�on, and
data cleansing tools to streamline data management processes.

• Performance Requirement:
Performance requirements define the system's ability to meet certain
performance criteria under specific condi�ons. These criteria include
response �me, throughput, scalability, availability, and reliability. For the
financial management system, performance requirements ensure efficient
and reliable opera�on, enabling users to access and process financial data
quickly and accurately.
1. Response Time: The system should respond to user queries within 2
seconds for standard opera�ons and within 5 seconds for complex
queries or data-intensive opera�ons.
2. Throughput: The system should be able to process a minimum of 100
transac�ons per second during peak usage periods.

16 | P a g e
 3. Scalability: The system should scale horizontally to accommodate a
20% increase in user load over the next three years without
performance degrada�on.
4. Availability: The system should be available for use 99.9% of the �me
during standard opera�onal hours, with planned maintenance
windows scheduled outside of peak usage periods.
5. Reliability: The system should have a mean �me between failures
(MTBF) of at least 10,000 hours, with automated failover mechanisms
in place to minimize down�me in the event of a failure.

• Non-Func�onal Requirement:
Non-func�onal requirements specify the quali�es or atributes that
the financial management system should possess beyond its func�onal
capabili�es. These requirements address aspects such as usability, security,
reliability, maintainability, and performance, ensuring that the system meets
user expecta�ons and organiza�onal objec�ves effec�vely.
1. Customiza�on: The system should allow users to customize their
interface preferences, such as language se�ngs, layout, and
personaliza�on op�ons, to enhance user experience and
produc�vity.
2. Data Encryp�on: The system should encrypt sensi�ve data in transit
and at rest using industry-standard encryp�on algorithms to
protect against unauthorized access and data breaches.
3. Access Control: The system should implement role-based access
control (RBAC) mechanisms to restrict access to sensi�ve
func�onality and data based on users' roles and permissions.
4. Audit Trails: The system should maintain detailed audit trails of user
ac�vi�es, including login atempts, data modifica�ons, and system
events, to track changes and detect unauthorized ac�ons.

17 | P a g e
 5. Fault Tolerance: The system should be resilient to failures and
errors, with built-in fault tolerance mechanisms such as
redundancy, failover, and error handling to ensure uninterrupted
opera�on and data integrity.
6. High Availability: The system should have high availability,
minimizing down�me and ensuring con�nuous access to cri�cal
func�onali�es, even during system maintenance or unexpected
disrup�ons.
7. Modularity: The system architecture should be modular and
extensible, allowing for easy maintenance, updates, and
enhancements without disrup�ng exis�ng func�onali�es.
8. Documenta�on: The system should have comprehensive
documenta�on, including user manuals, technical guides, and API
documenta�on, to facilitate system administra�on,
troubleshoo�ng, and development ac�vi�es.
9. Response Time: The system should respond to user requests
promptly, with acceptable response �mes for standard opera�ons
and transac�ons, ensuring op�mal user experience and
produc�vity.
10. Scalability: The system should scale horizontally or ver�cally to
accommodate increasing data volumes, user loads, and system
demands over �me without compromising performance or
reliability.

• Design Constraints:
1. Technology Stack:
• Angular Framework: The financial management system u�lizes Angular
for developing graphical user interfaces (GUI). This constraint dictates the
use of Angular-specific development prac�ces, libraries, and components
for frontend development.

18 | P a g e
 • Web Applica�on Deployment: The system is designed to run as a web
applica�on, imposing constraints on deployment environments, hos�ng
pla�orms, and compa�bility with web browsers.
• Server-Side Service: A server-side service component is integral to the
system architecture, responsible for controlling management
func�onali�es such as fee processing and salary management. This
constraint influences backend development decisions and integra�on
with the frontend.

2. Data Storage and Authen�ca�on:

• Google Firebase: The system leverages Google Firebase for data storage
and authen�ca�on services. This constraint necessitates adherence to
Firebase's data storage and security protocols, including data structuring,
authen�ca�on methods, and access control policies.

3. REST API Development:

• Node.js: The system u�lizes Node.js for developing the REST API layer of
the server-side service. This constraint dictates the use of JavaScript-
based development for backend logic, rou�ng, and interac�on with the
database and external services.

19 | P a g e
Lucid Chart Tool:
Lucid chart is a web-based diagramming applica�on that allows users
to visually collaborate on drawing, revising and sharing charts and diagrams,
and improve processes, systems, and organisa�onal structures

Lucid chart helps us visually solve complex problems by crea�ng

architectural diagrams and flowcharts that create clarity and help our
distributed team get up to speed quickly on codebase and systems. It allows
mul�ple team members to collaborate at the same �me, making it easy to
work across a fully distributed team.

• User Component Architectures:

Architecture is a part of the design. It is about making decision on how
the system will be built. So�ware system architecture is perhaps the most
important aspect that can be used to control the itera�ve and incremental
development to a system throughout its lifecycle.

1. Meet the current and future requirements.

2. Improve extensibility.
3. Enable reuse.
4. Encapsulate system dependencies.
5. Select from commercially available components.

• Model Visually (UML):

A model is a simplifica�on of reality that provides a complete
descrip�on of a system from a par�cular perspec�ve. We build models so
that we can understand the system we are modelling. The main reasons for
the modelling are:

1. Capture structure and technique.

2. Show how system elements fit together.
3. Keep design and implementa�on consistent.
4. Hide or expose details as appropriate.
5. Promote unambiguous communica�on.

20 | P a g e
 Modelling is important because it helps the development team
visualise, specify, construct and document the structure and the behaviour
of system architecture.
Visual modelling helps improve a team’s ability to manage so�ware
complexity. A diagram is a graphical representa�on of a set of elements,
most o�en rendered as a connected graph of ver�ces (things) and arcs
(rela�onships).

• Views:
Modelling complex systems is an extensive task. If the en�re system is
described and in a single graph that defines the en�re system
unambiguously and is easy to communicate and understand. However, this
is usually impossible. So there are several views describing the system in
depth with different diagrams. The views involved in UML are

i. Use Case View: a view describes the func�onality of the system as

perceived by an external actor. An actor interacts with the system; it
can be a user or another system. The use case view is for customers,
designers, developers and testers. The func�ons of the systems are
described as a number of use cases in the use case view. The systems
for some func�ons are represented by use cases.
ii. Logical View: A view showing the func�onality is designed inside the
system in terms of the system's sta�c structure and dynamic
behaviour. This is mainly for designers and developers. The sta�c
structure is described in class and object diagram. The dynamic
modelling is described in state, sequence collabora�on and ac�vity
diagrams.
iii. Component View: A view showing the organisa�on of the code
components. This view is a descrip�on of the implementa�on
modules and the dependencies. It is mainly for developers and
consists of the component diagram.
iv. Deployment View: A view showing the deployment of the system
into the physical architecture with computers and devices called
nodes and how they connect to each other. It is mainly for
developers and testers.

21 | P a g e
 v. Diagrams: The diagrams are the actual graphs that show model
element symbols of a system. There are different types of diagrams
to represent the systems func�onality and behaviour.
vi. Use-case Diagram: A use case diagram shows interac�ons of actors
with a system in terms of func�ons called use-case. A use case is
descrip�on of a func�onality that the system provides. The actors
are external to the system but who interacts with the system; they
may be external persons, external system and hardware.
vii. Class Diagram: A class diagram shows the sta�c structure of classes
in the system. The classes represent the “things” that are handled in
the system. Classes can be related to each other in a number of ways:
associated, dependent, specialised or packaged. Class represents
atributes and opera�ons.
viii. Object Diagram: An object diagram is a variant of the class diagram
and uses almost iden�cal nota�on. The difference between the two
is that an object diagram shows a number of object instances of
classes, instead of actual classes. Objects are writen in rectangular
box with their names. object diagrams are writen in rectangular box
with their names. Object diagrams are not important as class
diagrams, but show the actual instances of a class and the
rela�onships.
ix. State Diagram: A state diagram is typically a component to the
descrip�on of a class. It shows all possible states that the object of
the class can have and which events cause the state to change. An
event can be another object that sends a message to it. A change is
called a transi�on. State diagrams are not drawn for all classes, only
for those that have a number of well-defined states. State diagram
can also be drawn for the system as a whole.
x. Sequence Diagram: A sequence diagram shows a dynamic
collabora�on between a number of objects and shows an interac�on
between objects. This diagram shows a number of objects with
ver�cal lines that represent object lifeline. Messages passing
between objects are shown with arrows. This represents the
scenario of func�ons how they apply.
xi. Collabora�on Diagram: It is similar to a sequence diagram however
the rela�onships are only shown. If �me or sequence of events is
important then sequence diagrams are more relevant.
22 | P a g e
 xii. Ac�vity Diagram: An ac�vity diagram shows a sequen�al flow of
ac�vi�es. This is typically used to describe the ac�vi�es performed
in an opera�on.
xiii. Deployment Diagram: It represents the processors and devices to
develop the system, it shows deployment view of the system.
xiv. Component Diagram: A component diagram shows the physical
structure of the code in terms of code components. a component
can be a source code component, a binary component or an
executable component. A component contains informa�on about
logical class or classes it implements.

23 | P a g e
System Design:
• Data Flow Diagram:
A data flow diagram (DFD) maps out the flow of informa�on for any
process or system. It uses defined symbols like rectangles, circles and arrows,
plus short text labels, to show data inputs, outputs, storage points and the
routes between each des�na�on.
There exist three levels of data flow diagram:
1. Level 0(Context level DFD)
2. Level 1(High level DFD)
3. Level 2(Purified level DFD)

1. Level 0
This is the Zero Level DFD of Financial Management System, where
we have elaborated the high-level process of Financial. It's a basic
overview of the whole Financial Management System or process being
analysed or modelled. It's designed to be an at-a-glance view of Expenses,
Inventory and Login showing the system as a single high-level process, with
its rela�onship to external en��es of Accounts, Ledgers and Taxes

24 | P a g e
2. Level 1
First Level DFD (1st Level) of Financial Management System shows how
the system is divided into sub-systems (processes), each of which deals with
one or more of the data flows to or from an external agent, and which
together provide all of the func�onality of the Financial Management
System as a whole.

25 | P a g e
3. Level 2
This Use Case Diagram is a graphic depic�on of the interac�ons among
the elements of Finance Management System. It represents the
methodology used in system analysis to iden�fy, clarify, and organize system
requirement of Finance Management System. The main actors of Finance
Management System in this Use Case Diagram are: Super Admin, System
User, Accountant, Customer, who perform the different type of use cases
such as Manage Day Book, Manage Profit, Manage Loss, Manage Interest,
Manage Share Holders, Manage Loaner, Manage Users and Full Finance
Management System Opera�ons. Major elements of the UML use case
diagram of Finance Management System are shown on the picture below.

26 | P a g e
• Use-Case Diagram:
This Use Case Diagram is a graphic depic�on of the interac�ons among the
elements of Finance Management System. It represents the methodology used
in system analysis to iden�fy, clarify, and organize system requirements of
Finance Management System. The main actors of Finance Management
System in this Use Case Diagram are: Super Admin, System User, Accountant,
Customer, who perform the different type of use cases such as Manage Day
Book, Manage Profit, Manage Loss, Manage Interest, Manage Share Holders,
Manage Loaner, Manage Users and Full Finance Management System
Opera�ons. Major elements of the UML use case diagram of Finance
Management System are shown on the picture below.

The rela�onships between and among the actors and the use cases of
Finance Management System:
• Super Admin En�ty: Use cases of Super Admin are Manage Day Book,
Manage Profit, Manage Loss, Manage Interest, Manage Share Holders,
Manage Loaner, Manage Users and Full Finance Management System
Opera�ons
• System User En�ty: Use cases of System User are Manage Day Book,
Manage Profit, Manage Loss, Manage Interest, Manage Share Holders,
Manage Loaner
• Accountant En�ty: Use cases of Accountant are Create Balance Sheet, Check
Accounts, Review Accounts
• Customer En�ty: Use cases of Customer are Request for Loan, Upload
Documents, Check Loan Status.

27 | P a g e
28 | P a g e
• Ac�vity Diagram:
Ac�vity diagrams provide a way to model the workflow of a business
process. You can also use ac�vity diagrams to model code-specific informa�on
such as a class opera�on.

Ac�vity diagrams are very similar to a flowchart because you can model a
workflow from ac�vity to ac�vity. An ac�vity diagram is basically a special case
of a state machine in which most of the states are ac�vi�es and most of the
transi�ons are implicitly triggered by comple�on of the ac�ons in the source
ac�vi�es.

The main difference between ac�vity diagrams and state charts is ac�vity
diagrams are ac�vity centric, while state charts are state centric.
An ac�vity diagram is typically used for modelling the sequence of ac�vi�es in
a process, whereas a state chart is beter suited to model the discrete stages
of an object’s life�me

• Ac�vi�es: An ac�vity represents the performance of task or duty in a

workflow. It may also represent the execu�on of a statement in a
procedure. An ac�vity is similar to a state, but expresses the intent that
there is no significant wai�ng (for events) in an ac�vity. Transi�ons
connect ac�vi�es with other model elements and object flows connect
ac�vi�es with objects.

• Decisions: A decision represents a specific loca�on on an ac�vity diagram

or state chart diagram where the workflow may branch based upon guard
condi�ons. There may be more than two outgoing transi�ons with
different guard condi�ons, but for the most part, a decision will have only
two outgoing transi�ons determined by a Boolean expression.

29 | P a g e
 • End State: An end state represents a final or terminal state on an ac�vity
diagram or state chart diagram. Place an end state when you want to
explicitly show the end of a workflow on an ac�vity diagram or the end
of a state chart diagram. Transi�ons can only occur into an end state;
however, there can be any number of end states per context.

End

• Start State: A start state (also called an "ini�al state") explicitly shows the
beginning of a workflow on an ac�vity diagram or the beginning of the
execu�on of a state machine on a state chart diagram. You can have only
one start state for each state machine because each workflow/execu�on
of a state machine begins in the same place.

Start

This is the Ac�vity UML diagram of Financial Management System which

shows the flows between the ac�vity of Inventory, Investments, Accounts,
Ledgers, Taxes. The main ac�vity involved in this UML Ac�vity Diagram of
Financial Management System are as follows.

30 | P a g e
 This is the Login Ac�vity Diagram of Financial Management System, which
shows the flows of Login Ac�vity, where admin will be able to login using their
username and password. A�er login user can manage all the opera�ons on
Accounts, Inventory, Investments, Taxes, Ledgers. All the pages such as
Investments, Taxes, Ledgers are secure and user can access these pages a�er
login. The diagram below helps demonstrate how the login page works in a
Financial Management System. The various objects in the Taxes, Accounts,
Inventory, Investments, and Ledger’s page-interact over the course of the

31 | P a g e
Ac�vity, and user will not be able to access this page without
verifying their iden�ty.

Start

End

32 | P a g e
• Class Diagram:
A class diagram shows the existence of classes and their rela�onships in
the logical design of a system. A class diagram may represent all or part of
the class structure of a system.

A class diagram contains

1. Classes
2. Rela�onships
3. Interfaces

Classes:
A class is a set of objects that share a common structure and common
behaviour (the same atributes, opera�ons, rela�onships and seman�cs). A
class is an abstrac�on of real-world items. When these items exist in the
real world, they are instances of the class and are referred to as objects.

Rela�onships:
Associa�on Rela�onship:
An associa�on represents a bi-direc�onal rela�onship between two
classes. It indicates that instances of one class are connected to instances
of another class. Associa�ons are typically depicted as a solid line
connec�ng the classes, with op�onal arrows indica�ng the direc�on of the
rela�onship.

33 | P a g e
Directed Associa�on Rela�onship:
A directed associa�on in a UML class diagram represents a
rela�onship between two classes where the associa�on has a direc�on,
indica�ng that one class is associated with another in a specific way.

Aggrega�on Rela�onship:
Aggrega�on is a specialized form of associa�on that represents a
“whole-part” rela�onship. It denotes a stronger rela�onship where one
class (the whole) contains or is composed of another class (the part).
Aggrega�on is represented by a diamond shape on the side of the whole
class. In this kind of rela�onship, the child class can exist independently of
its parent class.

Special Aggrega�on Rela�onship:

A special type of aggregation where parts are destroyed when the
whole is destroyed.

Inheritance Rela�onship:
Inheritance represents an “is-a” rela�onship between classes, where
one class (the subclass or child) inherits the proper�es and behaviors of
another class (the superclass or parent). Inheritance is depicted by a solid
line with a closed, hollow arrowhead poin�ng from the subclass to the
superclass.

34 | P a g e
 Financial Management System Class Diagram describes the structure of a
Financial Management System classes, their atributes, opera�ons (or methods),
and the rela�onships among objects. The main classes of the Financial
Management System are Accounts, Ledgers, Taxes, Expenses, Inventory, Stock.

35 | P a g e
• Sequence Diagram:
A sequence diagram is a graphical view of a scenario that shows object
interac�on in a �me-based sequence¾what happens first, what happens next.
Sequence diagrams establish the roles of objects and help provide essen�al
informa�on to determine class responsibili�es and interfaces.
This type of diagram is best used during early analysis phases in design because
they are simple and easy to comprehend.
Sequence diagrams are normally associated with use cases. Sequence
diagrams are closely related to collabora�on diagrams and both are alternate
representa�ons of an interac�on.
A sequence diagram has two dimensions: typically, ver�cal placement
represents �me and horizontal placement represents different objects.
The following tools located on the sequence diagram toolbox enable you to
model sequence diagrams:

Actor:
It is a type of role played by an entity that interacts with the subject
(e.g., by exchanging signals and data). It represents roles played by human
users, external hardware, or other subjects.

36 | P a g e
 Lifeline:
A lifeline represents an individual participant in the Interaction.

Activations:
A thin rectangle on a lifeline) represents the period during which an
element is performing an operation. The top and the bottom of the of the
rectangle are aligned with the initiation and the completion time
respectively.

Call Message
• A message defines a particular communication between Lifelines of an
Interaction. Call message is a kind of message that represents an
invocation of operation of target lifeline.

37 | P a g e
 Return Message:
A message defines a particular communication between Lifelines of
an Interaction. Return message is a kind of message that represents the
pass of information back to the caller of a corresponded former message.

Self-Message:
A message defines a particular communication between Lifelines of
an Interaction. Self-message is a kind of message that represents the
invocation of message of the same lifeline.

Create Message:
A message defines a particular communication between Lifelines of
an Interaction. Create message is a kind of message that represents the
instantiation of (target) lifeline.

38 | P a g e
 This is the Login Sequence Diagram of Financial Management System,
where admin will be able to login in their account using their credentials.
After login user can manage all the operations on Expenses, Investments,
Taxes, Inventory, Accounts. All the pages such as Taxes, Inventory Accounts
are secure and user can access these pages after login. The diagram below
helps demonstrate how the login page works in a Financial Management
System. The various objects in the Inventory, Expenses, Investments, Taxes,
and Accounts page-interact over the course of the sequence, and user will
not be able to access this page without verifying their identity.

This is the UML sequence diagram of Financial Management System

which shows the interaction between the objects of Investements, Taxes,
Expenses, Accounts, Inventory. The in- stance of class objects involved in
this UML Sequence Diagram of Financial Management
System are as follows:
• Investment Object
• Taxes Object
39 | P a g e
• Expenses Object
• Account Object
• Inventory Object

40 | P a g e
• Component Diagram:
Component diagrams provide a physical view of the current model. A
component diagram shows the organisa�ons and dependencies among
so�ware components, including source code components, binary code
components, and executable components. These diagrams also show the
externally-visible behaviour of the components by displaying the interfaces of
the components. Calling dependencies among components are shown as
dependency rela�onships between components and interfaces on other
components. Note that the interfaces actually belong to the logical view, but
they can occur both in class diagrams and in component diagrams.
Component diagrams contain:

Component packages:
Component packages represent clusters of logically related components, or
major pieces of your system. Component packages parallel the role played by
logical packages for class diagrams. They allow you to par��on the physical
model of the system.

Components:
A component represents a so�ware module (source code, binary code,
executable, DLL, etc.) with a well-defined interface. The interface of a
component is represented by one or several interface elements that the
component provides. Components are used to show compiler and run-�me
dependencies, as well as interface and calling dependencies among so�ware
modules. They also show which components implement a specific class.
A system may be composed of several so�ware modules of different kinds.
Each so�ware module is represented by a component in the model. To
dis�nguish different kinds of components from each other, stereotypes are
used.

41 | P a g e
Interfaces:
An interface specifies the externally-visible opera�ons of a class and/or
component, and has no implementa�on of its own. An interface typically
specifies only a limited part of the behaviour of a class or component.

Dependency rela�onships:
A dependency is a rela�onship between two model elements in which a
change to one model element will affect the other model element. Use a
dependency rela�onship to connect model elements with the same level of
meaning. Typically, on class diagrams, a dependency rela�onship indicates that
the opera�ons of the client invoke opera�ons of the supplier.

This is a Component diagram of Financial Management System which shows

components, provided and re- quired interfaces, ports, and rela�onships
between the Accounts, Inventory, Investments, Taxes and Ledgers. This type of
diagrams is used in Component-Based Development (CBD) to describe systems
with Service- Oriented Architecture (SOA). Financial Management System UML

42 | P a g e
component diagram, describes the organiza�ons and wiring of the physical
components in a system.

43 | P a g e
• Deployment Diagram:
A deployment diagram shows processors, devices, and connec�ons. Each
model contains a single deployment diagram which shows the connec�ons
between its processors and devices, and the alloca�on of its processes to
processors.

Processor Specifica�ons, Device Specifica�ons, and Connec�on

Specifica�ons enable you to display and modify the respec�ve proper�es. The
informa�on in a specifica�on is presented textually; some of this informa�on
can also be displayed inside the icons.

You can change proper�es or rela�onships by edi�ng the specifica�on or

modifying the icon on the diagram. The deployment diagram specifica�ons are
automa�cally updated.

Processor:
A processor is a hardware component capable of execu�ng programs.

Devices:
A device is a hardware component with no compu�ng power. Each device
must have a name. Device names can be generic, such as "modem" or
"terminal."

Connec�ons:
A connec�on represents some type of hardware coupling between two
en��es. An en�ty is either a processor or a device. The hardware coupling can
be direct, such as an RS232 cable, or indirect, such as satellite-to-ground
communica�on. Connec�ons are usually bi-direc�onal.
ê ê ̉ ÄNJ ḟ ç ã ?Xì ¶Xì &J öJ ?öç ì J zX

NNç §ãö TXöJÄ̉î

?öJöXä Xãöî
$ ̉ ÄXãö&Xî Üöç ê F XM?Xì ¶ÄNX

*§ãT öìJãî ZXì $ §î öç ä Xì TXöJÄ̉î

44 | P a g e