Content uploaded by Vasile Daniel Pavaloaia
Author content
All content in this area was uploaded by Vasile Daniel Pavaloaia on Dec 11, 2016
Content may be subject to copyright.
METHODOLOGICAL APPROACHES TO COMPUTER MODELLING
POSSIBILITIES IN FINANCIAL ANALYSIS
Vasile-Daniel PĂVĂLOAIA
Faculty of Economics and Business Administration
Alexandru Ioan Cuza University
Iasi, Romania
danpav@uaic.ro
Abstract
The current research intention’ is to present some methodological approaches
regarding the possibilities of computerizing the field of financial analysis. Therefore, at first,
the characteristics, necessity and objectives of the financial analysis are clearly presented.
Secondly, the classical models of application development are compared within a table,
pointing out the advantaged versus the disadvantages of each model. Also, the agile models
are included for the purpose of deciding which model is the best suited for the analyzed
filed. Thirdly, the specific languages for enterprise modelling, namely UML language and
ontology are presented and specific ideas are formulated. The article states, at the end,
which methodology, model and modelling language is the best suited for computerizing the
field of financial analysis and also presents a conceptual computer modelling for financial
analysis.
Keywords: financial analysis, UML, system’s lifecycle models, agile models,
ontology
JEL classification: M41, M15, M49
1. INTRODUCTION
The increase in complexity of the phenomena that characterise the develop-
ment of production, of a firm’s activity in general and of financial aspects in
particular, have led to an exponential increase in the volume of data and infor-
mation operated from any field of financial activity. These changes have made the
management of any activity which unfolds in a competitive environment decisively
more difficult. From the small enterprises that look for the most diverse ways to
stand competition and up to large enterprises, there is an increasingly pressing need
for pertinent and opportune financial information. We wish to highlight the fact
that a financial analysis aims to establish causal links between factors and it consti-
tutes the basic instrument in the complex process of diagnosis and regulation of the
enterprise seen as a system. In order to maximize efficiency in any enterprise it be-
comes mandatory to carry out careful investigations and to use – to the maximum –
the computerised models designed to represent financial reality.
386 Vasile-Daniel PĂVĂLOAIA
In the proposed article we use a qualitative methodology in order to analyse
the specific literature and extract the financial ratios that should be included in our
proposed system. We also used the direct observation methodology in order to de-
velop the UML conceptual model that models the financial ratio system.
2. PARTICULAR FEATURES OF FINANCIAL ANALYSIS
The general activity of an enterprise can be measured through market success.
A thorough analysis of an enterprise’s financial indicators highlights both positive
and negative aspects. A financial analysis predominantly researches an enterprise’s
profitableness because the question of an enterprise’s yield and profitableness rises
in almost any context and situation.
2.1 The need for financial analyses
The analysis of these aspects is not to be neglected, given that corrective
measures can be taken only if the causes that have generated the need for such
measures are known. Also, the time needed to gather information plays a decisive
role. This is why the computerization and transfer of these aspects into an adequate
IT solution becomes the major premise for enterprises to successfully face compe-
tition and the current ”turbulences” in the financial field.
Financial analyses constitute the cluster of concepts, methods and instruments
that allow the formulation of the evaluation of an enterprise’s financial position, of
the risks that affect it, of the level and quality of its performance and they are based
on the operation and interpretation of accounting data or of other management in-
formation. Thus, a financial analysis contributes to the establishment of diagnosis
and to the control and evaluation of an enterprise’s activity, irrespective of its form
of ownership, of its specific line of business or type of organisation (Pavaloaia, et
al, 2009).
The development of financial analyses has been irrefutably stimulated by the
latest developments and financial priorities that have emerged over the past few
years and it can be seen in the spawning situations that require an enterprise’s di-
agnosis to be drawn. The above mentioned development is, in fact, a consequence
of the concurrent influence of several factors. On the one hand, enterprises are
faced with the increase of financial (and other) risks, which causes threats to hover
over financial results. The development of shares quoted on the stock exchange
makes the issue of shares and bonds gain increasing importance in financing an en-
terprise. Consequently, investors, potential buyers of shares, bonds, treasury bills
or of other financial instruments have to submit an enterprise’s position and per-
formance to an ongoing, vigilant exam. On the other hand, transactions that involve
these financial instruments represent considerable flows that impact the manage-
ment of money and equity and implicitly, of the economic agents’ patrimony. At
the same time, the influence of financial variables increases in the process of eval-
uation and elaboration of an enterprise’s development policy.
Methodological Approaches to Computer Modelling Possibilities in Financial Analysis 387
2.2 Fundamental objectives of financial analysis
The field of application of financial analysis has continuously extended and
increased, which proves that this discipline has met the new requirements made by
an enterprise’s multi-level financial management, control and governance. Thus,
among the main objectives suggested by this field, one may encounter the follow-
ing (Pavaloaia, et al, 2006).
1. to measure an enterprise’s profitableness. Profitableness is the economic
agents’ capacity to generate a positive output (profit), i.e. to spend less in
comparison with what they have produced, output which is then distributed and
capitalised on. It is examined from various perspectives:
- from the point of view of the enterprise manager, who is especially
concerned with the profitableness of the enterprise’s operations;
- from the point of view of the shareholders, for whom the net result (net
profit) and distributed dividends are essential elements, and they will be compared
with the capital employed;
- from the point of view of banks, in order to measure profitableness and
ensure that it is sufficient to guarantee a series of payments, as well as in order to
ensure the entity’s future development;
- the economic point of view will research and evaluate the enterprise’s
contribution at macroeconomic level. This means that the enterprise’s
profitableness will have to be measured in relation to various reporting criteria: the
economic and financial activity as such, capital employed and economic assets.
2. to assess the financial position and financial equilibrium. The general idea
of an enterprise’s equilibrium is based on the monetary means used to finance the
economic means employed in the production process. The economic means
susceptible to be used by an enterprise are made up of: fixed and current assets,
stocks, debts, clients.
This is why, our opinion is that fixed assets must be financed through perma-
nent capitals, more precisely equity and non-current liabilities (whose term is
longer than a year), while elements of current assets can be financed both through
durable capitals, and through non-durable capitals, sometimes also called provi-
sional/temporal capitals (suppliers’ credit, short-term bank loans).
The appraisal of the financial equilibrium will consist in measuring the securi-
ty margin represented by the excess of permanent financing (working capital) set
against the financing needs connected to the operational cycle (the necessary work-
ing capital).
Starting from these two elements, the general picture of how a financial anal-
ysis is made is captured in Figure no. 1 (Pavaloaia, 2008).
388 Vasile-Daniel PĂVĂLOAIA
Figure no. 1 General picture of the elements of a financial analysis
A simplistic model of financial analysis could start from the objectives of this
discipline, i.e. to ensure financial equilibrium and to study profitableness. Thus, we
think it necessary to approach these two aspects with a view to designing a concep-
tual model that would be specific to financial analyses. The analysis of the
financial equilibrium is performed based on data from the accounting balance
sheet, by using equilibrium indicators and the financing rate with the help of the
Working capital, the Necessary working capital and the Treasury (Dănuleţiu,
2006). The objective profitableness can be analysed by investigating specific rates:
the profit rate, the commercial profitableness rate, the economic profitableness rate,
the financial profitableness rate, the correlation between the economic profitable-
ness rate and the financial profitableness rate (Pavaloaia, 2009). Table no. 1
features the objectives of a financial analysis, carried out through the analysis of
specific indicators, to which we have added the calculus formulas.
Table no. 1 Financial analysis objectives
Financial
analysis
objectives
Rates specific to
the objective
Calculus formula
Source
Analysis of
financial
equilibrium
Working capital
WC=CA –STC
Accounting balance
sheet
Necessary working
capital
NWC=S +D - (STD -
STC)
Accounting balance
sheet
Treasury
T=WC-NWC
Accounting balance
sheet
Methodological Approaches to Computer Modelling Possibilities in Financial Analysis 389
Financial
analysis
objectives
Rates specific to
the objective
Calculus formula
Source
Analysis of
profitableness
Profit rate
R=(OP/TOC)*100
Accounting balance
sheet and Annexes
Commercial
profitableness rate
Cr=(OP/TO)*100
Accounting balance
sheet and Annexes
Economic
profitableness rate
Re=(GP/TA)*100
Accounting balance
sheet and Annexes
Financial
profitableness rate
Rf=(Np /Dc)*100
Accounting balance
sheet and Annexes
Legend: WC – Working Capital, CA – Current Assets, CL – Current liabilities, S -
Stocks, D - Debts, STD-Short-term debts, STC – Short-term credits, NWC –
Necessary working capital, OP-Operational Profit, TO – Turnover, TOC-Turn over
cost, OP-Operational Profit, GP-Gross Profit, TA-Total Assets, NP-Net Profit, Dc-
Durable capital
The conceptual model presented in Table no.1 could constitute a starting
point in the attempt to computerize financial analyses. Depending on the complexi-
ty of the application, it becomes imperative to extend the conceptual model by
adding new indicators or by developing existing indicators on hierarchical sub-
levels.
Our study aims to raise the interest of the scientific community, as well as the
interest of the managers who, in their departments, still use manual systems of fi-
nancial analysis. This is why, through technical and scientific arguments, we
attempt to persuade our readers of the need to give up the dated perspective and
commodity of manual data operation and partial computerization, which ignore the
impact of new technologies.
2.3 The importance of studying and implementing financial analyses in
enterprises
The main purpose of a financial analysis – one component of the economic
and financial analysis –, is to study and analyse all financial information that per-
tains to an economic entity. As financial information represents the actual results of
the economic entity vis-a-vis the structure and the strategies that it has adopted, a
careful analysis of the financial situation can significantly improve decisions that
will be made in the future.
A financial analysis uses specific instruments and means that are adapted to
the purpose it seeks to accomplish and it leads to financial diagnosis – one aspect
of the economic and financial diagnosis, together with the accounting diagnosis.
The latter concerns an enterprise’s financial and accounting function and is orient-
ed especially towards profitableness and its risks (Petrescu, 2008).
Although the analysis of financial statements is an operation of a high degree
of complexity, a general idea of the financial position of the economic entity can be
drawn from the analysis of ratios. Financial performance indicators can be deter-
mined starting from data in the accounting balance, in the profit or loss account and
in explanatory notes. These indicators are classified in five sub-groups: profit indi-
cators, cash flow indicators, management indicators, risk indicators: financial,
390 Vasile-Daniel PĂVĂLOAIA
economic and bankruptcy indicators, as well as ratios to recover shareholders’ in-
vestment.
The value of these indicators must be set against the average result registered
at the level of the economy or against the value of the enterprise’s performance for
the previous year. We must signal the fact that deviations from the average value
do not necessarily constitute a reason to worry; they just prevent more thorough in-
vestigations from being carried out. Apart from rate analysis, an enterprise’s
position mirrored by the study of treasury flows can constitute vital information
that must be studied, because it highlights an enterprise’s cash flow level.
From a historical point of view, the development of financial analysis became
apparent, at European and world level, in the aftermath of World War II. On the
whole, during the reconstruction periods that followed great world conflagrations,
the use of methods and instruments specific to the financial field evolved tremen-
dously and they made it possible for increasingly more telling analyses,
interpretations and forecasts to be drawn. Later, during the 1980’s, what the litera-
ture calls “financial revolution” imposed the need to analyse and interpret the
activity of many enterprises within the economy.
At present, the tendency in the field of financial analysis is characterised by
the steady increase in the number of requests for diagnosis and analyses of the en-
terprises’ performance and financial position. This increasing tendency is
generated by the convergence of four factors (Stanciu, 2006):
- over the last years, enterprises have been facing an increasingly varied range
of financial risks that impact both existent and potential business partners, and thus
indirectly influence the enterprises’ own situation and results;
- it has become a usual practice to finance enterprises by issuing shares and
bonds, and this aspect leads to the spectacular development of capital markets.
Potential investors who are interested in buying these financial instruments issued
by a certain enterprise wish to be as well informed as possible about the
performance of the issuing enterprise;
- transactions of financial instruments generate a considerable financial flow
that deeply influences the management of the treasury and of the patrimony of
individual investors, placement institutions and, finally, of enterprises;
- financial indicators have gained a vital importance in the process to evaluate
strategies that allow firms to develop harmoniously.
In our opinion, financial analyses are extremely necessary and opportune
within the decision-making process at the level of financial management, as they
show:
- how financial management can be carried out with a view to reaching the
enterprise’s strategic objectives;
- how an enterprise’s profit can be maximised;
- how the critical point is reached;
- how efficiency can be increased, especially by reducing costs per client;
- what the optimal level is for each category of operational expenses;
- how human resource costs must be managed as part the management of the
enterprise’s total human resources;
- how the phenomenon of inflation can be managed;
- what the enterprise’s policy is, connected to banking loan losses;
Methodological Approaches to Computer Modelling Possibilities in Financial Analysis 391
- how the enterprise’s cash flows must be managed;
- what the best form of financing is (the optimal combination between
commercial credits and an enterprise’s equity);
- the elements of the structure of an enterprise’s assets;
- how an enterprise’s fixed assets are managed (for instance: what policy is
used for amortisation, what financing or insurance method is used, etc.);
- what are the risks of foreign currency transactions and how they can be
minimised;
- how a series of future tendencies can be carried out and how achieved
performances can be compared to planned performances.
In most situations, financial analyses suppose collecting data over several
consecutive periods, an operation which is extremely difficult when no information
system is in place. An important stage in the analysis process consists in turning fi-
nancial and accounting data into information that can be used to calculate
indicators and analysis rates. Financial analyses mainly aim to reach an enterprise’s
solvency and profitableness objectives (Grama, 2008).
The aspects presented in this paragraph are as many reasons that explain why
our approaches have been gaining momentum and have been encouraging the use
of modern technologies for the purpose of computerization the field of financial
analysis.
3. METHODOLOGIES SPECIFIC TO SOFTWARE DEVELOPMENT
According to the particularities of the domain that is to be computerized, dif-
ferent methodologies and programming language will be used. Therefore,
according to the domain, different approaches will be taken as projects from differ-
ent domains ask for different work efforts and risks. Thus, we consider important
to review the most important methodologies so that a correct decision to be made
when is necessary to computerize the field of financial analysis.
3.1 Defining the relevant terms
A working methodology for a software product represents how the develop-
ment process is structured, planned and controlled.
The methodology to develop a system is a standard process, used by an enter-
prise in order to cover all the necessary stages for the analysis, design,
implementation and maintenance of information systems.
In what follows we shall present some terms that are associated to the concept
of working methodology:
- Methodology (or method) represents a collection of principles and/or
practices;
- Family of methodologies constitutes the set of coexisting alternative
methods;
- Framework can be likened to a frame (for methods) that must be developed
and personalised before being used;
- Model is o description (for methods) that must be implemented by a method,
family or framework.
392 Vasile-Daniel PĂVĂLOAIA
Methodology can be likened to a class that can be instantiated for a certain
project. A framework – working frame – can be considered an abstract class that
must first be inherited and extended. The model can be compared to an interface
that represents only a description which, later, must be implemented via classes.
3.2 Classical models specific to software development
The models specific to the development of systems represent a set of specifi-
cations that are necessary for the management of the stages in the development of
information systems. In general, these models have at least four stages: Planning
and selection, Analysis, Design, Implementation and maintenance (Valacich, 2012)
to which others can be added, depending on the model. In our opinion, is it worth
mentioning that: stages must not necessarily be sequential; each stage has certain
results and deliverables, and each organisation personalises the model of the life
cycle according to the specific profile of its operations.
Table no 2 features a comparative overview of the consecrated models in-
tended for software product development, also known in literature as system
development life cycle models (Oprea, et al 2005). Apart from this overview, the
table captures the advantages and disadvantages of the models, according to their
specific features mentioned in literature.
Table no. 2 Models of system life cycle
Model
title
Model overview
Advantages
Disadvantages
Water
-fall
Model
This is a reference
model that consists in
a process of sequential
implementation,
frequently used in
software product
development. The
model’s stages are:
Identification of
requests, Design,
Implementation,
Integration and
Maintenance.
- The documentation and
structure design represent an
advantage when new members
join the team;
- A simple model that is easy to
use by all team members;
- Each stage has an expected
outcome, as the model is rigid
(it imposes total control over
stages);
- Stages are implemented
individually, in order;
- It is recommended to be used
for small projects, in which
requirements are very clearly
formulated.
- Problems that emerged in one
stage are completely solved in
another stage;
- It does not allow to partition the
project according to stages;
- When new requirements are
formulated, they will be
implemented in another version.
Consequently, it imposes
supplementary costs for their
implementation;
- It is hard to give a correct
estimate of the time and cost
allotted for each stage;
- The finite product is obtained
quite late.
Proto-
type
Model
The model aims to
counter certain
limitations of the
Waterfall model and it is
developed starting from
currently known
requests. With the help of
the prototype, the
customer perceives more
easily how the
application functions
because he or she can
interact with it during the
development cycle. The
- Users are directly involved
in development and they can
better understand how the
application functions by
means of the prototype;
- Errors can be detected in
time’
- The user’s feedback is fast,
which leads to better
solutions;
- Less time and lower costs.
- The model leads to an increase
in the system’s complexity, and
it goes beyond the conditions
established at first;
- The project’s analysis is
insufficient;
- developers may become
attached to a prototype, out of
subjective reasons, running the
risk to transform the prototype
into a final product even though
the basic architecture is not
correct;
- It takes an excessive amount of
Methodological Approaches to Computer Modelling Possibilities in Financial Analysis 393
Model
title
Model overview
Advantages
Disadvantages
model is used in the case
of large and complex
systems.
time to implement a prototype.
Incre-
mental
model
The model is an evolved
form of the Waterfall
model. With its help, the
application can be
delivered incrementally.
The latter should have a
small scale, so that there
could be an interval
ranging from a few
weeks to maximum two
months between
launches. The model is
recommended for
projects that evolve in
time.
- The highest priorities are the
first to be delivered;
- Deliveries are done once in a
few weeks;
- The feedback on delivered
increments offers the
specifications for subsequent
increments;
- The model ensures a low risk
of total failure of the project;
- Higher priority increments
undergo an ampler testing
process.
- it may be necessary to create
temporary solutions so as to
deliver an increment in time;
- in some situations, a
significant part of the code
can be erased;
- under the circumstances,
planning is difficult.
V
Model
This is a variant of the
Waterfall model which
introduces new
concepts such as
system and
subsystems. The
model highlights the
demarcation between
the user’s
participation, the
architectural model
and the
implementation model.
- It can also be used in object-
oriented programming as it
favours the turning of higher
structures into prototypes and
their reuse;
- It provides a strong control
over the system, which allows
it to be used in the case of
complex systems as well;
- It encourages one to approach
the system according to its
constitutive parts.
- The major reproach that has
been brought to this model is
connected to the fact that the
validation stage is launched
late, which makes the system
suffer from the point of view
of efficiency.
Spiral
model
The model is based on
the convictions that:
- development and the
need to plan are iterative
in nature;
- it eliminates the
deficiency of the V
model in which
validation is done late;
this model does it earlier,
and it does it several
times even.
- It allows one to assess
risks at several moments;
- The model is characterised
by high flexibility (both in
fund allocation and in
defining activities).
- The allocated time and the
costs involved are hard to
estimate from the beginning.
We could add to the models in the table above the evolutionary model, the
three-dimensional model, the X model, the fountain model, the pinball model, the
baseball ball Model (it facilitates concurrent development), and the pyramid mod-
el.
3.3 Agile models
Apart from the classical models used in software product development, we
ought to mention the group of methods termed agile methods. They are based on
incremental and iterative development and they are mostly applied in cases that re-
394 Vasile-Daniel PĂVĂLOAIA
quire project specifications and solutions be the product of the collaboration be-
tween teams organised individually but which aim towards the same common
purpose.
Agile methods were developed starting from twelve principles included in the
“Agile Manifesto”, which we are going to list below:
1. Satisfying the customer requirements, through quick delivery of usable
software solutions;
2. Possibility to change specifications, no matter how late the product would
be in its implementation stage;
3. Software versions delivered very frequently;
4. The main measure of progress is usable software;
5. Development is at a steady pace, it can maintain a steady rhythm;
6. Close collaboration between developer and customer;
7. Face-to-face conversation is the best way to communicate;
8. Projects are made by motivated individuals of high credibility;
9. Simplicity;
10. Teams are organised individually;
11. Adaptation to changing circumstances;
12. Constant attention to technical excellence and quality design.
Among the most important agile methods we could mention the Extreme
Programming (XP) method and SCRUM. Table no. 3 gives an overview of the
characteristic features, of the advantages and disadvantages of each method.
Table no. 3 Basic characteristic features, advantages and disadvantages of agile methods
Method
title
Model
overview
Advantages
Disadvantages
Extreme
Progra-
mming
(XP)
The method
aims to lower
costs imposed
by changes in
requirements by
running several
shorter
implementation
cycles instead of
a long one. In
the XP
methodology
changes are a
natural aspect
and they must
be planned
instead of trying
to establish a
fixed and stable
set of
requirements.
XP supposes the
use of the
following four
- The method offers
quality projections and
software, and it
observes deadlines;
- It fully tests all
aspects, which provides
a high level of software
quality;
- It encourages team-
work;
- It offers a high level of
satisfaction of customer
requirements, through
the way in which the
latter are gathered;
- Test-cases are easy to
understand;
- The process of
development can be
completely visualised
and measured.
- It is hard to accomplish
because it requires large
teams of programmers and
much discipline is needed for
the project to be completed;
- The incremental design
proposed by XP does not
favour the current software
requirements;
- XP emphasises the
refactoring, in time, of the
implementation process,
which can diminish the
productivity of other aspects;
- The method imposes
development based on code
and not on design;
- Consequently, there is no
design documentation.
Methodological Approaches to Computer Modelling Possibilities in Financial Analysis 395
basic activities,
completed
during the
software
development
process: Code
writing, Testing,
Implementation
and Design.
SCRUM
The method can
be visualised as
a skeleton that
contains sets of
practices and
roles. The main
SCRUM roles
are: -“Scrum
Master” -
maintains
processes; -
“product holder”
– represents
investors and
the business;-
“Team”-7
employees who
are in charge
with analysis,
design and
implementation.
During every
“sprint” (which
can last from 2
to 4 weeks), the
team creates an
increment that
can be delivered
to the
beneficiary.
- It allows time and
money to be saved;
- It favours quick error
correction;
- It offers good
visibility of the
project’s
implementation;
- It offers permanent
feedback from partners;
- Possible problems can
be solved promptly
because they are
identified in the early
stages;
- It leads to the delivery
of quality products
within the planned
delivery schedule.
- The lack of a deadline
allows customers to ask for
more functionalities;
- If the team is not seriously
self-involved in the project,
the latter may fail;
- Requests must be well
defined in order to draw a
fair estimate of the costs and
time needed to complete the
project;
- The model is recommended
to be used only for small and
fast projects;
- If a member leaves the
team, this can massively
damage the project.
During the process of system development, enterprises must consider the var-
ious existing approaches and options. Thus, agile models will be opted for only
when the project involves (Boehm, 2004):
(1) requirements that are dynamic or hard to foresee;
(2) responsible and motivated developers;
(3) customers who are willing to get involved in the completion of the project.
The advocates of the agile methodology characterise it by the fact that it is
grounded in three key principles of operation, as follows: (1) it is focused more on
adaptive methodologies and not on predictive methodologies, (2) it complies with
employees’ requirements and not with their roles, (3) it supposes a self-adjusting
process.
396 Vasile-Daniel PĂVĂLOAIA
Table no. 4 provides a comparison between the agile methodology and
traditional approaches. In this context, the comparison focuses on five factors:
product size, information sensitivity, enterprise dynamics, employees and
environment/culture.
Table no. 4 Factors that differentiate system development: agile models vs. traditional
approaches
Analysed
factor
Agile
Models
Traditional
Methods
Dimension
Can be used with small-
size products and
teams. They are based
on tacit knowledge;
there are limitations at
the level of scalability.
They make it possible to manage large teams
and ample projects. They are difficult to use
with small projects.
Critical
projects
They have not been
tested in the case of
critical products.
Difficulties can occur
due to the simplicity of
design and the lack of
documentation.
They are sufficiently evolved to successfully
face critical products. Yet, they are hard to
use with small-scale critical projects.
Dynamism
Due to their simple
design and multiple
versions, they are
frequently used in
dynamic environments.
Their use in dynamic environments is very
expensive but they are considered an
excellent choice in stable environments.
Employees
They require the
massive presence of a
large number of
experts, who are
expensive and hard to
find. It is risky to use
employees who are not
familiar with agile
methods.
They require many experts only in the project
definition stage; subsequently, the project
can use few employees, on condition that the
field should be stable.
Environme
nt/ culture
enterprise
They thrive in
environments that offer
comfort and freedom to
their employees.
They are feasible in environments in which
employees have comfort and freedom and
roles are clearly defined through practices
and procedures.
Source: [adapted after Boehm, 2004]
4. MODELLING ENTERPRISE OPERATIONS
Economic systems must be correlated with the enterprise’s architecture
which, in turn, is closely connected to modelling languages. This is why we con-
sider that to approach enterprise operations modelling technologies in the current
article is fully motivated. In our attempt to answer the question Why do we need
modelling?, we shall present a series of reasons that highlight the importance of
this activity for economics. Thus, modelling (Marshall, 2000):
- offers a solid structure to the problem-solving process;
Methodological Approaches to Computer Modelling Possibilities in Financial Analysis 397
- allows experimentation so as to identify multiple solutions;
- supplies abstraction so as to manipulate complexity;
- contributes to the reduction of waiting time (time-to-market) to obtain
solutions to economic problems;
- lowers development costs;
- manages the risk of error occurrence and propagation.
In what follows we shall present the general characteristic features of UML
and ontology’s modelling languages.
4.1 UML modelling language
Between 1989 and 1994, practitioners could use more than 50 software mod-
elling languages and each of them had its own set of notations. Under the
circumstances, the users’ wish to have a standardised language, a lingua franca of
modelling, is easy to understand. Thus, in the mid 1990s, three methods proved to
be more efficient:
- The Booch method, suitable especially for the design and implementation
stages, had the disadvantage of using complicated notations;
- The OMT (Object Modelling Technique) method, suitable for the analysis
of information systems that had a large amount of data;
- The OOSE method (Object Oriented Software Engineering) suggested the
so-called use cases that were instrumental in the understanding of the entire
system.
In 1995, Ivar Jacobson, the creator of the OOSE method, capitalised on his
ideas (especially the concept of use cases) within the unified method, and the result
was termed the Unified Modelling Language - UML. Under the circumstances,
UML is considered the successor of the three modelling methods listed above, to
which it has added, among other things, a high level of expressiveness which helps
solve modelling problems.
The Unified Modelling Language is a graphic language meant for specifica-
tion, visualisation, development and documentation activities of the artefacts that
are specific to software products (Marshall, 2000). In time, UML has proved to be
not only a simple object-oriented modelling language but also a standard among
modelling languages, intensively used by software developers around the world.
This language was added on the OMG list of developed technologies, in No-
vember 1997, under the name of UML version 1.1, and the most recent version,
from August 2008, is 2.2.1.
Through excellence, UML contributes to model development and description.
A model captures a certain aspect that is particular to a programme; it can be de-
scribed along different levels of abstraction and a certain type of diagramme
corresponds to it. The following items are among the objectives of a UML devel-
opment team (Ștefănescu, 2007) (Stanciu, 2006) :
- to develop a modelling language that is easy to learn and, at the same time,
is a visual programme that is quite complex from a semantic point of view;
- to unify the languages that existed at that moment (year 1997), namely
Booch, OMT and OOSE, and to add the expressiveness that would contribute to
solving modelling problems;
398 Vasile-Daniel PĂVĂLOAIA
- to take ideas from other modelling languages;
- to incorporate the best practices on the market;
- to solve problems that are recurrent in the software development process;
- to supply a degree of flexibility in the use of development processes, that
would be as high as possible;
- to activate the possibility to alternate models and define interfaces.
A modelling language, just like any other language, use numerous concepts,
notations and sets of rules about how the latter are represented and used. Even
basic concepts can be modelled in UML, which is called recursive definition or
meta-modelling. Thus, each meta-model describes modelling elements and the
rules about how they can be composed in the process of building models. The fact
that UML is ranked with “visualisation languages” and that one UML modelling is
considered “visual” derives from the fact that the notation used in this language in-
cludes graphic symbols that are easy to interpret (Anica-Popa, 2004).
Essentially, UML can be defined as the model visualisation, specification,
construction and documentation language. Among its main particular features and
advantages, we could list the following:
- it allows complex models to be built via a standard and rigorous modelling
language, (this is an open standard);
- it models the entire life cycle of software products development;
- it does not automatically guarantee the success of the developed
applications, yet it ensures the improvement of many elements that pertain to the
development process;
- it covers a varied range of types of applications;
- it is based on the vast experience of its authors;
- it is used by many CASE-type products.
In UML, building blocks are made up of things, relations and diagrammes,
and their typology is briefly presented in Table no. 5.
Table no. 5 Typology of UML specific elements that can be used within a financial analysis
specific model
Source: [adapted after Ștefănescu, 2007, pp.9-12]
Methodological Approaches to Computer Modelling Possibilities in Financial Analysis 399
A large diversity of problems can be modelled via UML, including problems
specific to economics and finance. For this reason, we hold that the field of finan-
cial analysis can be modelled optimally by resorting to UML. Once a specific
model had been obtained for financial analysis by using UML, this model can then
be taken over by an add-on computer application and it can be integrated in an ERP
system, within a Business intelligence or ScoreCard component. Such integration
would be useful to the application that would benefit from the computerisation of
the other modules/systems by taking from them the necessary information to feed
financial indicators. In our wish to illustrate the modelling of financial statements
with the help of UML, in Figure 2 we present a class diagramme based on the
model of the accounting balance sheet.
Figure no. 2 Example of a class diagramme for the accounting balance
Figure no. 3 captures, in a nutshell, our view on how an application functions.
This application has been developed on the financial analysis conceptual model
(presented in Table 1) developed by relying on UML activity diagramme. Thus, the
diagramme captures three distinct sub-systems, which communicate through asyn-
chronous signals. In order to present how systems communicate, signal-type
objects have been used, whose purpose is to initiate asynchronous communication
from the sales management sub-system to the financial and accounting operational
sub-system and then further, to the financial and accounting decision-making sub-
system. In UML there are two types of signals: outgoing and incoming signals. The
outgoing signal acts on the operation’s transition of state and it is represented
through a convex polygon, while the incoming signal is represented by a concave
polygon (Andone, et all., 2004).
Within the sales management system there are a series of operations that run
in parallel (more precisely: Product delivery and Invoice fill out-Invoice dispatch-
Payment-Payment acceptance and the operation corresponding to sending the sig-
nal to do the accounting registration of the sales transaction); this is why fork and
join elements have been used to suggest the operation coordination flow. The dif-
400 Vasile-Daniel PĂVĂLOAIA
ferent degrees of granularity in the three sub-systems is justified by the wish to
highlight especially the decision-making process which runs in parallel with the
process that determines indicator results and interprets their values.
Thus, in the sector or partition corresponding to the financial-accounting deci-
sion-making sub-system, detailed modelling is initiated. The conceptual model
suggests the calculus of indicators specific to financial analysis objectives, present-
ed in Table no. 1, and the issuing results will be interpreted according to limits
taken over from literature. In the case of a non-interpretable result, the model cal-
culates indicators again, which signals that there must have been an error; in the
case of a non-favourable result, decision-making management is informed so as to
take immediate decisions (Pavaloaia, 2008).
Figure no. 3 Activity diagramme that is specific to the conceptual model
The advantages of using UML are numerous; among them, we mention the
following:
- all use cases make up the entire system;
- it enables communication with persons who do not have IT technical
knowledge;
- it partitions functionality;
- it supports planning and testing stages;
- it helps create user’s manuals.
4.2 Ontologies and information modelling
Ontologies are any specification of a conceptualisation and, broadly, they can
include almost any type of model or representation, taxonomies, entity-relation di-
Methodological Approaches to Computer Modelling Possibilities in Financial Analysis 401
agrammes, flowcharts etc. Initially, ontologies developed due to the discipline
called Artificial Intelligence; more precisely, ontologies developed by drawing on
representations and knowledge reasoning, and on formal logic. Today, ontologies
have evolved and have come to be able to represent complex relations that are
characterized by a formal semantic language.
The language specific to ontologies makes it possible to use fundamental
modelling constructions so as to develop specific ontologies. These languages in-
clude constructions specific to classes, properties, instances and other formal
constructions that reflect inter-relations between variants and the constraints that
might exist between them.
The constructions used in ontologies include classes (or concepts), instances
(or individuals, characteristics) and properties (or relations), elements that contain
complex sets of possible roles, inter-relations and constraints.
Instances correspond to individual aspects to which properties are associated;
classes constitute groupings of elements, and properties are the links between them.
In general, there is acceptable compatibility between ontologies and other
methods, and the purpose of ontologies is not to replace them but to enhance value.
To illustrate this view, in what follows we shall present the differences between
ontologies and other technologies, in a comparative perspective.
Ontologies and data model
While data model can be the result of a conceptual analysis and can facilitate
the design of a database, data model, as such, is not directly connected to data
while ontologies represent their explicit mapping, and they are strongly connected.
By updating the data model, for instance the entity-relation diagramme, new in-
formation is not generated automatically whereas ontology updates have the
purpose to automatically generate new information. The data model is not as ex-
pressive as ontologies.
Ontologies and UML
The UML specific modelling language is different from ontologic languages
because it offers more specificity as it is not meant to model data only but also pro-
cesses, cases etc. However, UML is not directly or dynamically connected to
represented information and it does not allow automated reasoning to be per-
formed. In the long run, it is expected that standard UML notations for ontologies
will be created, and that there will be a convergence between ontologies and UML.
In the short run, we hope an instrument will be created to import data models from
UML into an ontology editor.
Ontologies and data bases
Although data can be stored in ontologies, in general, ontology editors are not
optimised for such operations, nor are they recommended except in the case of
small-scale data sets. Consequently, it has been suggested to combine the use of
ontologies with the data base technology so as to obtain a virtual conceptual per-
spective on data, in the sense of activating inter-operability and amplifying the
value of data bases.
Ontologies and taxonomies
Although the two concepts are somehow related, taxonomies have a tree-
structure while the structure of ontologies is graphic, and they can enable the mul-
tiple inheritances of features and the connection with them. Ontologies have higher
402 Vasile-Daniel PĂVĂLOAIA
valences in terms of capturing relations in comparison with basic taxonomies such
as “is-a” relations. Consequently, taxonomies can be seen as very simple sets of
ontologies.
Ontologies and expert systems
Ontologies can be considered fact bases because they operate explicit
knowledge, they can use rules and offer support for deductive skills. The use of on-
tologies is expected to allow intelligent future agents to incorporate certain
properties foreseen to be achieved by expert systems.
By using the language specific to ontologies, a model is constructed in order
to represent information about a certain field of interest. This structure can be lik-
ened to that of a pattern which contains, on the one hand, specifications about
logical concepts and on the other hand, relations and constraints that must be satis-
fied for each particular situation.
5. CONCLUSIONS AND FUTURE RESEARCH PATHS
In our opinion, computerised and conceptual modelling in financial analysis
supposes undertaking a theoretical study of the methods that will be used, identify-
ing a fertile area, specific to the field of financial analysis that lends itself to
modelling, and structuring it.
The theoretical approach to computerised modelling shows that the enterprise
model consists in the computerised representation of an enterprise’s structure, ac-
tivities, processes, information, resources, employees, behaviours, purposes and
constraints. Thus, from the point of view of the design stage, the enterprise model
must offer a specialised language meant to define the enterprise as explicitly as
possible. In general, the classical models of the software products life cycle contain
four large stages: Planning and selection, Analysis, Design, Implementation and
maintenance, to which other stages can be added if the case may be.
Agile models have been developed by programmers out of their wish to be as
efficient as possible in successfully completing projects. These models are opposed
to the classical models that offer the beneficiary the possibility to test the product
only at the end. Thus, agile methods launch new versions weekly and they incorpo-
rate the beneficiaries’ specifications from one version to another. Under the
circumstances, we consider that such an approach could be successful in the devel-
opment of applications for the field of financial analysis.
As far as UML is concerned, it allows the modelling of a large range of prob-
lems, including problems specific to the financial field. UML is a very general
modelling language that can be extended to specific fields, including economic and
financial analysis, thus simplifying the language’s generic structure and generating
stand-alone applications or applications that can be integrated in other software
products.
In the current article it was proposed an original contribution, namely the
conceptual model that highlights the advantages of using UML in the specific case
of financial analysis. The activity diagramme illustrated in figure no.3 displays the
link between 3 subsystems of the enterprise, namely Sale management system, Ac-
counting and financial operational system, Accounting and financial decisional
system. Basically, the conceptual model presented in Table no.1 constitutes a start-
Methodological Approaches to Computer Modelling Possibilities in Financial Analysis 403
ing point in the attempt to computerize a proposed ratio system for the financial
analysis of an enterprise. Therefore, in the last column of the activity diagramme, it
is described in details the conceptual model of analysing the formula result for all
the ratios included in our system: profitableness ratios and financial equilibrium ra-
tios. The UML language is by far the best tool that should be used in developing a
conceptual model for the financial analysis. In the subsequent research, the author
aims to develop the proposed model and to identify how it can be integrated in al-
ready existing Business intelligence or ScoreCard applications. In this sense, the
model proposed here represents one way of solving a decision-making problem,
specific to financial analysis, within the enterprise’s accounting information sys-
tem.
Acknowledgements
This work was supported by the project "Post-Doctoral Studies in Economics: training
program for elite researchers - SPODE" co-funded from the European Social Fund through
the Development of Human Resources Operational Programme 2007-2013, contract no.
POSDRU/89/1.5/S/61755).
References
[1] Andone, I., Păvăloaia, V.D., Bâcâin, I., Genete, L., 2004, Modelarea cunoașterii în
organizații, Ed. Tehnopress, Iași.
[2] Anica-Popa, L., 2004. Proiectarea obiectuală UML a unui sistem de gestiune a
costurilor unei organizaţii prin metoda abc – diagramele cazurilor de utilizare şi ale
claselor, Revista Româna de Informatică şi Automatică, vol. 14, no. 3.
[3] Boehm, B, Turner, R., 2004. Balancing Agility and Discipline: Evaluating and Inte-
grating Agile and Plan-Driven Methods. Proceedings of the 26th International
Conference on Software Engineering. Washington, DC, USA.
[4] Dănuleţiu, A., 2006. Analiza echilibrului financiar al întreprinderii, Analele Universi-
tăţii din Oradea, Vol. Finanţe-Contabilitate şi Bănci, p.491-495.
[5] Grama, A., Pavaloaia, D., 2008. Comparative Analysis using Bankruptcy Prediction
Models. An online computer-based system, Proceedings of the 2nd European Compu-
ting Conference: New Aspects On Computers Research, 2nd ECC, Malta.
[6] Marshall, C., 2000. Enterprise modelling with UML. Designing succesful software
through business analysis, Addison Wesley.
[7] Oprea, D., Meşniţă, G., Dumitriu, F., 2005. Analiza sistemelor informaţionale, Edi-
tura Universităţii "Alexandru Ioan Cuza" Iaşi.
[8] Pavaloaia, V.D., 2008, Integrarea tehnologiilor informationale în analiza financiară,
Ed. Universităţii "Alexandru Ioan Cuza", Iaşi.
[9] Pavaloaia, V.D., 2009. Web Based Application for SMEs Economic and Financial Di-
agnose, Innovation and Knowledge Management in Twin Track Economies:
Challenges & Solutions, VOLS 1-3, 11th International-Business-Information-
Management-Association Conference, Cairo, Egypt, Jan 04-06.
[10] Pavaloaia, V.D., Andone, I., 2011. The Advantages Vs. the Disadvantages of Out-
sourcing The Accounting and Financial Service, AMIS 2011 - Proceedings of The 6th
International Conference, Accounting And Management Information Systems , Bu-
charest, Romania.
[11] Pavaloaia, W., ş.a., 2009. Analiza economico-financiară, Ed. Tehnopress Iaşi.
[12] Pavaloaia, W., Pavaloaia, V.D., 2006. Diagnosticul şi evaluarea întreprinderii,
Ed.Tehnopress, Iaşi.
404 Vasile-Daniel PĂVĂLOAIA
[13] Petrescu, S., 2008. Analiză și diagnostic financiar-contabil, Ghid teoretico-aplicativ,
Ediția a II-a, Ed. C.E.C.C.A.R., București.
[14] Stanciu, A., 2006. Modelul unui sistem informatic de asistare a deciziei generalizabil
pentru activitatea financiar-contabilă, ASE Bucureşti.
[15] Ștefănescu, G., 2007. UML: Modelare structurală și comportamentală, Ed. Universi-
tății București.
[16] Valacich, J., George, J., Hoffer, J., 2012. Essentials of Systems Analysis and Design,
5/E, Prentice Hall.
