Initialize project documentation
Add architecture documentation and functional requirements for Calminer project - Created Building Block View (05_building_block_view.md) detailing system architecture and component interactions. - Developed Runtime View (06_runtime_view.md) outlining key user scenarios and interactions within the system. - Established Deployment View (07_deployment_view.md) describing the infrastructure and mapping of building blocks to deployment components. - Added README.md for architecture documentation structure. - Introduced functional requirements (FR-001 to FR-010) covering scenario management, data import/export, reporting, user management, and collaboration features. - Included templates for documenting requirements to ensure consistency across the project.
This commit is contained in:
675
LICENSE.md
Normal file
675
LICENSE.md
Normal file
@@ -0,0 +1,675 @@
|
||||
# GNU GENERAL PUBLIC LICENSE
|
||||
|
||||
Version 3, 29 June 2007
|
||||
|
||||
Copyright (C) 2007 Free Software Foundation, Inc.
|
||||
<https://fsf.org/>
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies of this
|
||||
license document, but changing it is not allowed.
|
||||
|
||||
## Preamble
|
||||
|
||||
The GNU General Public License is a free, copyleft license for
|
||||
software and other kinds of works.
|
||||
|
||||
The licenses for most software and other practical works are designed
|
||||
to take away your freedom to share and change the works. By contrast,
|
||||
the GNU General Public License is intended to guarantee your freedom
|
||||
to share and change all versions of a program--to make sure it remains
|
||||
free software for all its users. We, the Free Software Foundation, use
|
||||
the GNU General Public License for most of our software; it applies
|
||||
also to any other work released this way by its authors. You can apply
|
||||
it to your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
them if you wish), that you receive source code or can get it if you
|
||||
want it, that you can change the software or use pieces of it in new
|
||||
free programs, and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to prevent others from denying you
|
||||
these rights or asking you to surrender the rights. Therefore, you
|
||||
have certain responsibilities if you distribute copies of the
|
||||
software, or if you modify it: responsibilities to respect the freedom
|
||||
of others.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must pass on to the recipients the same
|
||||
freedoms that you received. You must make sure that they, too, receive
|
||||
or can get the source code. And you must show them these terms so they
|
||||
know their rights.
|
||||
|
||||
Developers that use the GNU GPL protect your rights with two steps:
|
||||
(1) assert copyright on the software, and (2) offer you this License
|
||||
giving you legal permission to copy, distribute and/or modify it.
|
||||
|
||||
For the developers' and authors' protection, the GPL clearly explains
|
||||
that there is no warranty for this free software. For both users' and
|
||||
authors' sake, the GPL requires that modified versions be marked as
|
||||
changed, so that their problems will not be attributed erroneously to
|
||||
authors of previous versions.
|
||||
|
||||
Some devices are designed to deny users access to install or run
|
||||
modified versions of the software inside them, although the
|
||||
manufacturer can do so. This is fundamentally incompatible with the
|
||||
aim of protecting users' freedom to change the software. The
|
||||
systematic pattern of such abuse occurs in the area of products for
|
||||
individuals to use, which is precisely where it is most unacceptable.
|
||||
Therefore, we have designed this version of the GPL to prohibit the
|
||||
practice for those products. If such problems arise substantially in
|
||||
other domains, we stand ready to extend this provision to those
|
||||
domains in future versions of the GPL, as needed to protect the
|
||||
freedom of users.
|
||||
|
||||
Finally, every program is threatened constantly by software patents.
|
||||
States should not allow patents to restrict development and use of
|
||||
software on general-purpose computers, but in those that do, we wish
|
||||
to avoid the special danger that patents applied to a free program
|
||||
could make it effectively proprietary. To prevent this, the GPL
|
||||
assures that patents cannot be used to render the program non-free.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
## TERMS AND CONDITIONS
|
||||
|
||||
### 0. Definitions.
|
||||
|
||||
"This License" refers to version 3 of the GNU General Public License.
|
||||
|
||||
"Copyright" also means copyright-like laws that apply to other kinds
|
||||
of works, such as semiconductor masks.
|
||||
|
||||
"The Program" refers to any copyrightable work licensed under this
|
||||
License. Each licensee is addressed as "you". "Licensees" and
|
||||
"recipients" may be individuals or organizations.
|
||||
|
||||
To "modify" a work means to copy from or adapt all or part of the work
|
||||
in a fashion requiring copyright permission, other than the making of
|
||||
an exact copy. The resulting work is called a "modified version" of
|
||||
the earlier work or a work "based on" the earlier work.
|
||||
|
||||
A "covered work" means either the unmodified Program or a work based
|
||||
on the Program.
|
||||
|
||||
To "propagate" a work means to do anything with it that, without
|
||||
permission, would make you directly or secondarily liable for
|
||||
infringement under applicable copyright law, except executing it on a
|
||||
computer or modifying a private copy. Propagation includes copying,
|
||||
distribution (with or without modification), making available to the
|
||||
public, and in some countries other activities as well.
|
||||
|
||||
To "convey" a work means any kind of propagation that enables other
|
||||
parties to make or receive copies. Mere interaction with a user
|
||||
through a computer network, with no transfer of a copy, is not
|
||||
conveying.
|
||||
|
||||
An interactive user interface displays "Appropriate Legal Notices" to
|
||||
the extent that it includes a convenient and prominently visible
|
||||
feature that (1) displays an appropriate copyright notice, and (2)
|
||||
tells the user that there is no warranty for the work (except to the
|
||||
extent that warranties are provided), that licensees may convey the
|
||||
work under this License, and how to view a copy of this License. If
|
||||
the interface presents a list of user commands or options, such as a
|
||||
menu, a prominent item in the list meets this criterion.
|
||||
|
||||
### 1. Source Code.
|
||||
|
||||
The "source code" for a work means the preferred form of the work for
|
||||
making modifications to it. "Object code" means any non-source form of
|
||||
a work.
|
||||
|
||||
A "Standard Interface" means an interface that either is an official
|
||||
standard defined by a recognized standards body, or, in the case of
|
||||
interfaces specified for a particular programming language, one that
|
||||
is widely used among developers working in that language.
|
||||
|
||||
The "System Libraries" of an executable work include anything, other
|
||||
than the work as a whole, that (a) is included in the normal form of
|
||||
packaging a Major Component, but which is not part of that Major
|
||||
Component, and (b) serves only to enable use of the work with that
|
||||
Major Component, or to implement a Standard Interface for which an
|
||||
implementation is available to the public in source code form. A
|
||||
"Major Component", in this context, means a major essential component
|
||||
(kernel, window system, and so on) of the specific operating system
|
||||
(if any) on which the executable work runs, or a compiler used to
|
||||
produce the work, or an object code interpreter used to run it.
|
||||
|
||||
The "Corresponding Source" for a work in object code form means all
|
||||
the source code needed to generate, install, and (for an executable
|
||||
work) run the object code and to modify the work, including scripts to
|
||||
control those activities. However, it does not include the work's
|
||||
System Libraries, or general-purpose tools or generally available free
|
||||
programs which are used unmodified in performing those activities but
|
||||
which are not part of the work. For example, Corresponding Source
|
||||
includes interface definition files associated with source files for
|
||||
the work, and the source code for shared libraries and dynamically
|
||||
linked subprograms that the work is specifically designed to require,
|
||||
such as by intimate data communication or control flow between those
|
||||
subprograms and other parts of the work.
|
||||
|
||||
The Corresponding Source need not include anything that users can
|
||||
regenerate automatically from other parts of the Corresponding Source.
|
||||
|
||||
The Corresponding Source for a work in source code form is that same
|
||||
work.
|
||||
|
||||
### 2. Basic Permissions.
|
||||
|
||||
All rights granted under this License are granted for the term of
|
||||
copyright on the Program, and are irrevocable provided the stated
|
||||
conditions are met. This License explicitly affirms your unlimited
|
||||
permission to run the unmodified Program. The output from running a
|
||||
covered work is covered by this License only if the output, given its
|
||||
content, constitutes a covered work. This License acknowledges your
|
||||
rights of fair use or other equivalent, as provided by copyright law.
|
||||
|
||||
You may make, run and propagate covered works that you do not convey,
|
||||
without conditions so long as your license otherwise remains in force.
|
||||
You may convey covered works to others for the sole purpose of having
|
||||
them make modifications exclusively for you, or provide you with
|
||||
facilities for running those works, provided that you comply with the
|
||||
terms of this License in conveying all material for which you do not
|
||||
control copyright. Those thus making or running the covered works for
|
||||
you must do so exclusively on your behalf, under your direction and
|
||||
control, on terms that prohibit them from making any copies of your
|
||||
copyrighted material outside their relationship with you.
|
||||
|
||||
Conveying under any other circumstances is permitted solely under the
|
||||
conditions stated below. Sublicensing is not allowed; section 10 makes
|
||||
it unnecessary.
|
||||
|
||||
### 3. Protecting Users' Legal Rights From Anti-Circumvention Law.
|
||||
|
||||
No covered work shall be deemed part of an effective technological
|
||||
measure under any applicable law fulfilling obligations under article
|
||||
11 of the WIPO copyright treaty adopted on 20 December 1996, or
|
||||
similar laws prohibiting or restricting circumvention of such
|
||||
measures.
|
||||
|
||||
When you convey a covered work, you waive any legal power to forbid
|
||||
circumvention of technological measures to the extent such
|
||||
circumvention is effected by exercising rights under this License with
|
||||
respect to the covered work, and you disclaim any intention to limit
|
||||
operation or modification of the work as a means of enforcing, against
|
||||
the work's users, your or third parties' legal rights to forbid
|
||||
circumvention of technological measures.
|
||||
|
||||
### 4. Conveying Verbatim Copies.
|
||||
|
||||
You may convey verbatim copies of the Program's source code as you
|
||||
receive it, in any medium, provided that you conspicuously and
|
||||
appropriately publish on each copy an appropriate copyright notice;
|
||||
keep intact all notices stating that this License and any
|
||||
non-permissive terms added in accord with section 7 apply to the code;
|
||||
keep intact all notices of the absence of any warranty; and give all
|
||||
recipients a copy of this License along with the Program.
|
||||
|
||||
You may charge any price or no price for each copy that you convey,
|
||||
and you may offer support or warranty protection for a fee.
|
||||
|
||||
### 5. Conveying Modified Source Versions.
|
||||
|
||||
You may convey a work based on the Program, or the modifications to
|
||||
produce it from the Program, in the form of source code under the
|
||||
terms of section 4, provided that you also meet all of these
|
||||
conditions:
|
||||
|
||||
- a) The work must carry prominent notices stating that you modified
|
||||
it, and giving a relevant date.
|
||||
- b) The work must carry prominent notices stating that it is
|
||||
released under this License and any conditions added under
|
||||
section 7. This requirement modifies the requirement in section 4
|
||||
to "keep intact all notices".
|
||||
- c) You must license the entire work, as a whole, under this
|
||||
License to anyone who comes into possession of a copy. This
|
||||
License will therefore apply, along with any applicable section 7
|
||||
additional terms, to the whole of the work, and all its parts,
|
||||
regardless of how they are packaged. This License gives no
|
||||
permission to license the work in any other way, but it does not
|
||||
invalidate such permission if you have separately received it.
|
||||
- d) If the work has interactive user interfaces, each must display
|
||||
Appropriate Legal Notices; however, if the Program has interactive
|
||||
interfaces that do not display Appropriate Legal Notices, your
|
||||
work need not make them do so.
|
||||
|
||||
A compilation of a covered work with other separate and independent
|
||||
works, which are not by their nature extensions of the covered work,
|
||||
and which are not combined with it such as to form a larger program,
|
||||
in or on a volume of a storage or distribution medium, is called an
|
||||
"aggregate" if the compilation and its resulting copyright are not
|
||||
used to limit the access or legal rights of the compilation's users
|
||||
beyond what the individual works permit. Inclusion of a covered work
|
||||
in an aggregate does not cause this License to apply to the other
|
||||
parts of the aggregate.
|
||||
|
||||
### 6. Conveying Non-Source Forms.
|
||||
|
||||
You may convey a covered work in object code form under the terms of
|
||||
sections 4 and 5, provided that you also convey the machine-readable
|
||||
Corresponding Source under the terms of this License, in one of these
|
||||
ways:
|
||||
|
||||
- a) Convey the object code in, or embodied in, a physical product
|
||||
(including a physical distribution medium), accompanied by the
|
||||
Corresponding Source fixed on a durable physical medium
|
||||
customarily used for software interchange.
|
||||
- b) Convey the object code in, or embodied in, a physical product
|
||||
(including a physical distribution medium), accompanied by a
|
||||
written offer, valid for at least three years and valid for as
|
||||
long as you offer spare parts or customer support for that product
|
||||
model, to give anyone who possesses the object code either (1) a
|
||||
copy of the Corresponding Source for all the software in the
|
||||
product that is covered by this License, on a durable physical
|
||||
medium customarily used for software interchange, for a price no
|
||||
more than your reasonable cost of physically performing this
|
||||
conveying of source, or (2) access to copy the Corresponding
|
||||
Source from a network server at no charge.
|
||||
- c) Convey individual copies of the object code with a copy of the
|
||||
written offer to provide the Corresponding Source. This
|
||||
alternative is allowed only occasionally and noncommercially, and
|
||||
only if you received the object code with such an offer, in accord
|
||||
with subsection 6b.
|
||||
- d) Convey the object code by offering access from a designated
|
||||
place (gratis or for a charge), and offer equivalent access to the
|
||||
Corresponding Source in the same way through the same place at no
|
||||
further charge. You need not require recipients to copy the
|
||||
Corresponding Source along with the object code. If the place to
|
||||
copy the object code is a network server, the Corresponding Source
|
||||
may be on a different server (operated by you or a third party)
|
||||
that supports equivalent copying facilities, provided you maintain
|
||||
clear directions next to the object code saying where to find the
|
||||
Corresponding Source. Regardless of what server hosts the
|
||||
Corresponding Source, you remain obligated to ensure that it is
|
||||
available for as long as needed to satisfy these requirements.
|
||||
- e) Convey the object code using peer-to-peer transmission,
|
||||
provided you inform other peers where the object code and
|
||||
Corresponding Source of the work are being offered to the general
|
||||
public at no charge under subsection 6d.
|
||||
|
||||
A separable portion of the object code, whose source code is excluded
|
||||
from the Corresponding Source as a System Library, need not be
|
||||
included in conveying the object code work.
|
||||
|
||||
A "User Product" is either (1) a "consumer product", which means any
|
||||
tangible personal property which is normally used for personal,
|
||||
family, or household purposes, or (2) anything designed or sold for
|
||||
incorporation into a dwelling. In determining whether a product is a
|
||||
consumer product, doubtful cases shall be resolved in favor of
|
||||
coverage. For a particular product received by a particular user,
|
||||
"normally used" refers to a typical or common use of that class of
|
||||
product, regardless of the status of the particular user or of the way
|
||||
in which the particular user actually uses, or expects or is expected
|
||||
to use, the product. A product is a consumer product regardless of
|
||||
whether the product has substantial commercial, industrial or
|
||||
non-consumer uses, unless such uses represent the only significant
|
||||
mode of use of the product.
|
||||
|
||||
"Installation Information" for a User Product means any methods,
|
||||
procedures, authorization keys, or other information required to
|
||||
install and execute modified versions of a covered work in that User
|
||||
Product from a modified version of its Corresponding Source. The
|
||||
information must suffice to ensure that the continued functioning of
|
||||
the modified object code is in no case prevented or interfered with
|
||||
solely because modification has been made.
|
||||
|
||||
If you convey an object code work under this section in, or with, or
|
||||
specifically for use in, a User Product, and the conveying occurs as
|
||||
part of a transaction in which the right of possession and use of the
|
||||
User Product is transferred to the recipient in perpetuity or for a
|
||||
fixed term (regardless of how the transaction is characterized), the
|
||||
Corresponding Source conveyed under this section must be accompanied
|
||||
by the Installation Information. But this requirement does not apply
|
||||
if neither you nor any third party retains the ability to install
|
||||
modified object code on the User Product (for example, the work has
|
||||
been installed in ROM).
|
||||
|
||||
The requirement to provide Installation Information does not include a
|
||||
requirement to continue to provide support service, warranty, or
|
||||
updates for a work that has been modified or installed by the
|
||||
recipient, or for the User Product in which it has been modified or
|
||||
installed. Access to a network may be denied when the modification
|
||||
itself materially and adversely affects the operation of the network
|
||||
or violates the rules and protocols for communication across the
|
||||
network.
|
||||
|
||||
Corresponding Source conveyed, and Installation Information provided,
|
||||
in accord with this section must be in a format that is publicly
|
||||
documented (and with an implementation available to the public in
|
||||
source code form), and must require no special password or key for
|
||||
unpacking, reading or copying.
|
||||
|
||||
### 7. Additional Terms.
|
||||
|
||||
"Additional permissions" are terms that supplement the terms of this
|
||||
License by making exceptions from one or more of its conditions.
|
||||
Additional permissions that are applicable to the entire Program shall
|
||||
be treated as though they were included in this License, to the extent
|
||||
that they are valid under applicable law. If additional permissions
|
||||
apply only to part of the Program, that part may be used separately
|
||||
under those permissions, but the entire Program remains governed by
|
||||
this License without regard to the additional permissions.
|
||||
|
||||
When you convey a copy of a covered work, you may at your option
|
||||
remove any additional permissions from that copy, or from any part of
|
||||
it. (Additional permissions may be written to require their own
|
||||
removal in certain cases when you modify the work.) You may place
|
||||
additional permissions on material, added by you to a covered work,
|
||||
for which you have or can give appropriate copyright permission.
|
||||
|
||||
Notwithstanding any other provision of this License, for material you
|
||||
add to a covered work, you may (if authorized by the copyright holders
|
||||
of that material) supplement the terms of this License with terms:
|
||||
|
||||
- a) Disclaiming warranty or limiting liability differently from the
|
||||
terms of sections 15 and 16 of this License; or
|
||||
- b) Requiring preservation of specified reasonable legal notices or
|
||||
author attributions in that material or in the Appropriate Legal
|
||||
Notices displayed by works containing it; or
|
||||
- c) Prohibiting misrepresentation of the origin of that material,
|
||||
or requiring that modified versions of such material be marked in
|
||||
reasonable ways as different from the original version; or
|
||||
- d) Limiting the use for publicity purposes of names of licensors
|
||||
or authors of the material; or
|
||||
- e) Declining to grant rights under trademark law for use of some
|
||||
trade names, trademarks, or service marks; or
|
||||
- f) Requiring indemnification of licensors and authors of that
|
||||
material by anyone who conveys the material (or modified versions
|
||||
of it) with contractual assumptions of liability to the recipient,
|
||||
for any liability that these contractual assumptions directly
|
||||
impose on those licensors and authors.
|
||||
|
||||
All other non-permissive additional terms are considered "further
|
||||
restrictions" within the meaning of section 10. If the Program as you
|
||||
received it, or any part of it, contains a notice stating that it is
|
||||
governed by this License along with a term that is a further
|
||||
restriction, you may remove that term. If a license document contains
|
||||
a further restriction but permits relicensing or conveying under this
|
||||
License, you may add to a covered work material governed by the terms
|
||||
of that license document, provided that the further restriction does
|
||||
not survive such relicensing or conveying.
|
||||
|
||||
If you add terms to a covered work in accord with this section, you
|
||||
must place, in the relevant source files, a statement of the
|
||||
additional terms that apply to those files, or a notice indicating
|
||||
where to find the applicable terms.
|
||||
|
||||
Additional terms, permissive or non-permissive, may be stated in the
|
||||
form of a separately written license, or stated as exceptions; the
|
||||
above requirements apply either way.
|
||||
|
||||
### 8. Termination.
|
||||
|
||||
You may not propagate or modify a covered work except as expressly
|
||||
provided under this License. Any attempt otherwise to propagate or
|
||||
modify it is void, and will automatically terminate your rights under
|
||||
this License (including any patent licenses granted under the third
|
||||
paragraph of section 11).
|
||||
|
||||
However, if you cease all violation of this License, then your license
|
||||
from a particular copyright holder is reinstated (a) provisionally,
|
||||
unless and until the copyright holder explicitly and finally
|
||||
terminates your license, and (b) permanently, if the copyright holder
|
||||
fails to notify you of the violation by some reasonable means prior to
|
||||
60 days after the cessation.
|
||||
|
||||
Moreover, your license from a particular copyright holder is
|
||||
reinstated permanently if the copyright holder notifies you of the
|
||||
violation by some reasonable means, this is the first time you have
|
||||
received notice of violation of this License (for any work) from that
|
||||
copyright holder, and you cure the violation prior to 30 days after
|
||||
your receipt of the notice.
|
||||
|
||||
Termination of your rights under this section does not terminate the
|
||||
licenses of parties who have received copies or rights from you under
|
||||
this License. If your rights have been terminated and not permanently
|
||||
reinstated, you do not qualify to receive new licenses for the same
|
||||
material under section 10.
|
||||
|
||||
### 9. Acceptance Not Required for Having Copies.
|
||||
|
||||
You are not required to accept this License in order to receive or run
|
||||
a copy of the Program. Ancillary propagation of a covered work
|
||||
occurring solely as a consequence of using peer-to-peer transmission
|
||||
to receive a copy likewise does not require acceptance. However,
|
||||
nothing other than this License grants you permission to propagate or
|
||||
modify any covered work. These actions infringe copyright if you do
|
||||
not accept this License. Therefore, by modifying or propagating a
|
||||
covered work, you indicate your acceptance of this License to do so.
|
||||
|
||||
### 10. Automatic Licensing of Downstream Recipients.
|
||||
|
||||
Each time you convey a covered work, the recipient automatically
|
||||
receives a license from the original licensors, to run, modify and
|
||||
propagate that work, subject to this License. You are not responsible
|
||||
for enforcing compliance by third parties with this License.
|
||||
|
||||
An "entity transaction" is a transaction transferring control of an
|
||||
organization, or substantially all assets of one, or subdividing an
|
||||
organization, or merging organizations. If propagation of a covered
|
||||
work results from an entity transaction, each party to that
|
||||
transaction who receives a copy of the work also receives whatever
|
||||
licenses to the work the party's predecessor in interest had or could
|
||||
give under the previous paragraph, plus a right to possession of the
|
||||
Corresponding Source of the work from the predecessor in interest, if
|
||||
the predecessor has it or can get it with reasonable efforts.
|
||||
|
||||
You may not impose any further restrictions on the exercise of the
|
||||
rights granted or affirmed under this License. For example, you may
|
||||
not impose a license fee, royalty, or other charge for exercise of
|
||||
rights granted under this License, and you may not initiate litigation
|
||||
(including a cross-claim or counterclaim in a lawsuit) alleging that
|
||||
any patent claim is infringed by making, using, selling, offering for
|
||||
sale, or importing the Program or any portion of it.
|
||||
|
||||
### 11. Patents.
|
||||
|
||||
A "contributor" is a copyright holder who authorizes use under this
|
||||
License of the Program or a work on which the Program is based. The
|
||||
work thus licensed is called the contributor's "contributor version".
|
||||
|
||||
A contributor's "essential patent claims" are all patent claims owned
|
||||
or controlled by the contributor, whether already acquired or
|
||||
hereafter acquired, that would be infringed by some manner, permitted
|
||||
by this License, of making, using, or selling its contributor version,
|
||||
but do not include claims that would be infringed only as a
|
||||
consequence of further modification of the contributor version. For
|
||||
purposes of this definition, "control" includes the right to grant
|
||||
patent sublicenses in a manner consistent with the requirements of
|
||||
this License.
|
||||
|
||||
Each contributor grants you a non-exclusive, worldwide, royalty-free
|
||||
patent license under the contributor's essential patent claims, to
|
||||
make, use, sell, offer for sale, import and otherwise run, modify and
|
||||
propagate the contents of its contributor version.
|
||||
|
||||
In the following three paragraphs, a "patent license" is any express
|
||||
agreement or commitment, however denominated, not to enforce a patent
|
||||
(such as an express permission to practice a patent or covenant not to
|
||||
sue for patent infringement). To "grant" such a patent license to a
|
||||
party means to make such an agreement or commitment not to enforce a
|
||||
patent against the party.
|
||||
|
||||
If you convey a covered work, knowingly relying on a patent license,
|
||||
and the Corresponding Source of the work is not available for anyone
|
||||
to copy, free of charge and under the terms of this License, through a
|
||||
publicly available network server or other readily accessible means,
|
||||
then you must either (1) cause the Corresponding Source to be so
|
||||
available, or (2) arrange to deprive yourself of the benefit of the
|
||||
patent license for this particular work, or (3) arrange, in a manner
|
||||
consistent with the requirements of this License, to extend the patent
|
||||
license to downstream recipients. "Knowingly relying" means you have
|
||||
actual knowledge that, but for the patent license, your conveying the
|
||||
covered work in a country, or your recipient's use of the covered work
|
||||
in a country, would infringe one or more identifiable patents in that
|
||||
country that you have reason to believe are valid.
|
||||
|
||||
If, pursuant to or in connection with a single transaction or
|
||||
arrangement, you convey, or propagate by procuring conveyance of, a
|
||||
covered work, and grant a patent license to some of the parties
|
||||
receiving the covered work authorizing them to use, propagate, modify
|
||||
or convey a specific copy of the covered work, then the patent license
|
||||
you grant is automatically extended to all recipients of the covered
|
||||
work and works based on it.
|
||||
|
||||
A patent license is "discriminatory" if it does not include within the
|
||||
scope of its coverage, prohibits the exercise of, or is conditioned on
|
||||
the non-exercise of one or more of the rights that are specifically
|
||||
granted under this License. You may not convey a covered work if you
|
||||
are a party to an arrangement with a third party that is in the
|
||||
business of distributing software, under which you make payment to the
|
||||
third party based on the extent of your activity of conveying the
|
||||
work, and under which the third party grants, to any of the parties
|
||||
who would receive the covered work from you, a discriminatory patent
|
||||
license (a) in connection with copies of the covered work conveyed by
|
||||
you (or copies made from those copies), or (b) primarily for and in
|
||||
connection with specific products or compilations that contain the
|
||||
covered work, unless you entered into that arrangement, or that patent
|
||||
license was granted, prior to 28 March 2007.
|
||||
|
||||
Nothing in this License shall be construed as excluding or limiting
|
||||
any implied license or other defenses to infringement that may
|
||||
otherwise be available to you under applicable patent law.
|
||||
|
||||
### 12. No Surrender of Others' Freedom.
|
||||
|
||||
If conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot convey a
|
||||
covered work so as to satisfy simultaneously your obligations under
|
||||
this License and any other pertinent obligations, then as a
|
||||
consequence you may not convey it at all. For example, if you agree to
|
||||
terms that obligate you to collect a royalty for further conveying
|
||||
from those to whom you convey the Program, the only way you could
|
||||
satisfy both those terms and this License would be to refrain entirely
|
||||
from conveying the Program.
|
||||
|
||||
### 13. Use with the GNU Affero General Public License.
|
||||
|
||||
Notwithstanding any other provision of this License, you have
|
||||
permission to link or combine any covered work with a work licensed
|
||||
under version 3 of the GNU Affero General Public License into a single
|
||||
combined work, and to convey the resulting work. The terms of this
|
||||
License will continue to apply to the part which is the covered work,
|
||||
but the special requirements of the GNU Affero General Public License,
|
||||
section 13, concerning interaction through a network will apply to the
|
||||
combination as such.
|
||||
|
||||
### 14. Revised Versions of this License.
|
||||
|
||||
The Free Software Foundation may publish revised and/or new versions
|
||||
of the GNU General Public License from time to time. Such new versions
|
||||
will be similar in spirit to the present version, but may differ in
|
||||
detail to address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the Program
|
||||
specifies that a certain numbered version of the GNU General Public
|
||||
License "or any later version" applies to it, you have the option of
|
||||
following the terms and conditions either of that numbered version or
|
||||
of any later version published by the Free Software Foundation. If the
|
||||
Program does not specify a version number of the GNU General Public
|
||||
License, you may choose any version ever published by the Free
|
||||
Software Foundation.
|
||||
|
||||
If the Program specifies that a proxy can decide which future versions
|
||||
of the GNU General Public License can be used, that proxy's public
|
||||
statement of acceptance of a version permanently authorizes you to
|
||||
choose that version for the Program.
|
||||
|
||||
Later license versions may give you additional or different
|
||||
permissions. However, no additional obligations are imposed on any
|
||||
author or copyright holder as a result of your choosing to follow a
|
||||
later version.
|
||||
|
||||
### 15. Disclaimer of Warranty.
|
||||
|
||||
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
|
||||
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
|
||||
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
|
||||
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
|
||||
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
||||
A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
|
||||
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
|
||||
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
|
||||
CORRECTION.
|
||||
|
||||
### 16. Limitation of Liability.
|
||||
|
||||
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR
|
||||
CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
|
||||
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
|
||||
ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT
|
||||
NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR
|
||||
LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM
|
||||
TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER
|
||||
PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
|
||||
|
||||
### 17. Interpretation of Sections 15 and 16.
|
||||
|
||||
If the disclaimer of warranty and limitation of liability provided
|
||||
above cannot be given local legal effect according to their terms,
|
||||
reviewing courts shall apply local law that most closely approximates
|
||||
an absolute waiver of all civil liability in connection with the
|
||||
Program, unless a warranty or assumption of liability accompanies a
|
||||
copy of the Program in return for a fee.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
## How to Apply These Terms to Your New Programs
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these
|
||||
terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest to
|
||||
attach them to the start of each source file to most effectively state
|
||||
the exclusion of warranty; and each file should have at least the
|
||||
"copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
<one line to give the program's name and a brief idea of what it does.>
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This program is free software: you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation, either version 3 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program. If not, see <https://www.gnu.org/licenses/>.
|
||||
|
||||
Also add information on how to contact you by electronic and paper
|
||||
mail.
|
||||
|
||||
If the program does terminal interaction, make it output a short
|
||||
notice like this when it starts in an interactive mode:
|
||||
|
||||
<program> Copyright (C) <year> <name of author>
|
||||
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
|
||||
This is free software, and you are welcome to redistribute it
|
||||
under certain conditions; type `show c' for details.
|
||||
|
||||
The hypothetical commands \`show w' and \`show c' should show the
|
||||
appropriate parts of the General Public License. Of course, your
|
||||
program's commands might be different; for a GUI interface, you would
|
||||
use an "about box".
|
||||
|
||||
You should also get your employer (if you work as a programmer) or
|
||||
school, if any, to sign a "copyright disclaimer" for the program, if
|
||||
necessary. For more information on this, and how to apply and follow
|
||||
the GNU GPL, see <https://www.gnu.org/licenses/>.
|
||||
|
||||
The GNU General Public License does not permit incorporating your
|
||||
program into proprietary programs. If your program is a subroutine
|
||||
library, you may consider it more useful to permit linking proprietary
|
||||
applications with the library. If this is what you want to do, use the
|
||||
GNU Lesser General Public License instead of this License. But first,
|
||||
please read <https://www.gnu.org/licenses/why-not-lgpl.html>.
|
||||
83
README.md
Normal file
83
README.md
Normal file
@@ -0,0 +1,83 @@
|
||||
# Calminer Documentation
|
||||
|
||||
Welcome to the Calminer documentation! This guide provides an overview of the Calminer project, its features, installation instructions, and usage guidelines.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Calminer Documentation](#calminer-documentation)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Introduction](#introduction)
|
||||
- [Overview](#overview)
|
||||
- [Purpose](#purpose)
|
||||
- [Key Features](#key-features)
|
||||
- [Architecture](#architecture)
|
||||
- [Installation](#installation)
|
||||
- [Usage](#usage)
|
||||
- [API Reference](#api-reference)
|
||||
- [Contributing](#contributing)
|
||||
- [FAQ](#faq)
|
||||
- [Changelog](#changelog)
|
||||
- [License](#license)
|
||||
- [Contact](#contact)
|
||||
- [Acknowledgements](#acknowledgements)
|
||||
|
||||
Feel free to explore each section for more detailed information about Calminer!
|
||||
|
||||
## Introduction
|
||||
|
||||
### Overview
|
||||
|
||||
CalMiner is designed to assist mining companies in optimizing their project planning and financial analysis processes. By leveraging advanced algorithms and data analytics, CalMiner enables users to make informed decisions and improve the overall efficiency of their mining operations.
|
||||
|
||||
### Purpose
|
||||
|
||||
The purpose of CalMiner is to provide a comprehensive toolset for mining professionals to streamline their workflows, enhance project evaluation, and maximize profitability. It aims to address the challenges faced by the mining industry through innovative solutions and user-friendly interfaces.
|
||||
|
||||
### Key Features
|
||||
|
||||
- Advanced project planning tools
|
||||
- Financial analysis and reporting
|
||||
- Data integration capabilities
|
||||
- Advanced analytics and machine learning
|
||||
- User-friendly interface
|
||||
- Custom reporting options
|
||||
|
||||
## Architecture
|
||||
|
||||
We use arc42 as a template for documenting our architecture. Please see [Architecture Documentation](architecture/README.md) for a detailed description of the system architecture, including components and their interactions.
|
||||
|
||||
## Installation
|
||||
|
||||
Instructions for installing Calminer can be found in the [Installation](admin/installation.md) section of the documentation. Follow the steps outlined there to set up Calminer on your system.
|
||||
|
||||
## Usage
|
||||
|
||||
Usage instructions for Calminer can be found in the [Usage](userguide/README.md) section of the documentation. This includes guidelines and examples for using Calminer effectively.
|
||||
|
||||
## API Reference
|
||||
|
||||
The API reference for Calminer is available in the [API Reference](api/README.md) section of the documentation. This includes detailed information about the available endpoints, request/response formats, and usage examples.
|
||||
|
||||
## Contributing
|
||||
|
||||
We welcome contributions to Calminer! Please see the [Contributing Guidelines](CONTRIBUTING.md) for more information on how to get involved.
|
||||
|
||||
## FAQ
|
||||
|
||||
Find answers to common questions about Calminer in the [FAQ](FAQ.md) section of the documentation.
|
||||
|
||||
## Changelog
|
||||
|
||||
The changelog for Calminer can be found in the [Changelog](CHANGELOG.md) section of the documentation. This includes a history of changes, updates, and improvements made to the project.
|
||||
|
||||
## License
|
||||
|
||||
This project is licensed under the GNU General Public License v3.0. See the [LICENSE](LICENSE) file for more details.
|
||||
|
||||
## Contact
|
||||
|
||||
For support or inquiries, please contact the Calminer team at [calminer@allucanget.biz](mailto:calminer@allucanget.biz).
|
||||
|
||||
## Acknowledgements
|
||||
|
||||
We would like to thank all contributors and third-party resources that have helped make Calminer possible.
|
||||
57
architecture/01_introduction_and_goals.md
Normal file
57
architecture/01_introduction_and_goals.md
Normal file
@@ -0,0 +1,57 @@
|
||||
# Introduction and Goals
|
||||
|
||||
CalMiner aims to provide a comprehensive platform for mining project scenario analysis, enabling stakeholders to make informed decisions based on data-driven insights.
|
||||
|
||||
## Business Goals
|
||||
|
||||
- **Optimize Project Planning**: Provide tools that help mining companies plan projects more effectively by analyzing various scenarios and their potential outcomes.
|
||||
- **Enhance Financial Analysis**: Enable detailed financial assessments of mining projects to support investment decisions.
|
||||
- **Improve Decision-Making**: Offer data-driven insights that empower stakeholders to make informed choices regarding mining operations.
|
||||
|
||||
## Driving Forces
|
||||
|
||||
| Driving Force | Rationale |
|
||||
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Market Demand | There is a growing need for advanced analytics in the mining industry to optimize operations and reduce costs. |
|
||||
| Regulatory Compliance | Mining companies must adhere to strict regulations regarding environmental impact and resource management, necessitating robust analysis tools. |
|
||||
| Technological Advancements | Rapid advancements in data analytics and machine learning present opportunities for more sophisticated scenario analysis. |
|
||||
| Stakeholder Collaboration | Increased collaboration among stakeholders requires a platform that facilitates shared access to data and insights. |
|
||||
| Sustainability Goals | Increased focus on sustainable practices, driving the need for tools that can assess environmental and social impacts alongside financial metrics. |
|
||||
| Cost Reduction | Mining companies are under constant pressure to reduce operational costs, making efficient and effective analysis tools essential. |
|
||||
| Dynamic Market Conditions | The volatility of commodity prices and market conditions necessitates flexible and adaptive scenario planning capabilities. |
|
||||
| Data Integration | The ability to integrate diverse data sources, including geological, financial, and operational data, is crucial for comprehensive analysis. |
|
||||
|
||||
## Key Features
|
||||
|
||||
- Advanced project planning tools
|
||||
- Financial analysis and reporting
|
||||
- Data integration capabilities
|
||||
- Advanced analytics and machine learning
|
||||
- User-friendly interface
|
||||
- Custom reporting options
|
||||
- Collaboration tools
|
||||
|
||||
## Functional Requirements
|
||||
|
||||
A detailed list of functional requirements can be found in the [Requirements Document](../requirements/requirements.md). Key functionalities include project planning tools, financial analysis modules, and data integration capabilities.
|
||||
|
||||
## Quality Goals
|
||||
|
||||
| Quality Goal | Scenario | Priority |
|
||||
| ------------------------------- | ------------------------------------------------------------------------------------------------------- | -------- |
|
||||
| Comprehensive Scenario Analysis | Users can create and analyze multiple project scenarios to assess risks and opportunities. | High |
|
||||
| Data-Driven Decision Making | Stakeholders have access to real-time data and analytics to inform their decisions. | High |
|
||||
| User-Friendly Interface | The platform is designed with an intuitive interface that requires minimal training for new users. | Medium |
|
||||
| Security | Sensitive data is protected through robust security measures, including encryption and access controls. | Medium |
|
||||
| Scalability | The system can handle increasing amounts of data and users without performance degradation. | Low |
|
||||
| Maintainability | The architecture allows for easy updates and maintenance with minimal downtime. | Low |
|
||||
|
||||
## Stakeholders
|
||||
|
||||
| Stakeholder | Role/Interest |
|
||||
| -------------------- | -------------------------------------------------------------------------------------------- |
|
||||
| Mining Companies | Primary users interested in optimizing project planning and financial analysis. |
|
||||
| Project Managers | Responsible for overseeing mining projects and ensuring successful execution. |
|
||||
| Financial Analysts | Focused on evaluating the financial viability of mining projects using the platform's tools. |
|
||||
| Executive Leadership | Interested in high-level insights and strategic decision-making based on scenario analyses. |
|
||||
| Investors | Concerned with the financial performance and risk assessment of mining projects. |
|
||||
139
architecture/02_architecture_constraints.md
Normal file
139
architecture/02_architecture_constraints.md
Normal file
@@ -0,0 +1,139 @@
|
||||
# Architecture Constraints
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Architecture Constraints](#architecture-constraints)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Technical Constraints](#technical-constraints)
|
||||
- [Framework Selection](#framework-selection)
|
||||
- [Database Technology](#database-technology)
|
||||
- [Frontend Technologies](#frontend-technologies)
|
||||
- [Simulation Logic](#simulation-logic)
|
||||
- [Organizational and Political Constraints](#organizational-and-political-constraints)
|
||||
- [Team Expertise](#team-expertise)
|
||||
- [Development Processes](#development-processes)
|
||||
- [Collaboration Tools](#collaboration-tools)
|
||||
- [Documentation Standards](#documentation-standards)
|
||||
- [Knowledge Sharing](#knowledge-sharing)
|
||||
- [Resource Availability](#resource-availability)
|
||||
- [Regulatory Constraints](#regulatory-constraints)
|
||||
- [Data Privacy Compliance](#data-privacy-compliance)
|
||||
- [Industry Standards](#industry-standards)
|
||||
- [Auditability](#auditability)
|
||||
- [Data Retention Policies](#data-retention-policies)
|
||||
- [Security Standards](#security-standards)
|
||||
- [Environmental Constraints](#environmental-constraints)
|
||||
- [Deployment Environments](#deployment-environments)
|
||||
- [Cloud Provider Limitations](#cloud-provider-limitations)
|
||||
- [Containerization](#containerization)
|
||||
- [Scalability Requirements](#scalability-requirements)
|
||||
- [Performance Constraints](#performance-constraints)
|
||||
- [Response Time](#response-time)
|
||||
- [Scalability Needs](#scalability-needs)
|
||||
- [Conventions](#conventions)
|
||||
- [Programming Language](#programming-language)
|
||||
- [Versioning](#versioning)
|
||||
|
||||
## Technical Constraints
|
||||
|
||||
### Framework Selection
|
||||
|
||||
The choice of FastAPI as the web framework imposes constraints on how the application handles requests, routing, and middleware. FastAPI's asynchronous capabilities must be leveraged appropriately to ensure optimal performance.
|
||||
|
||||
### Database Technology
|
||||
|
||||
The use of PostgreSQL as the primary database system dictates the data modeling, querying capabilities, and transaction management strategies. SQLAlchemy ORM is used for database interactions, which requires adherence to its conventions and limitations.
|
||||
|
||||
### Frontend Technologies
|
||||
|
||||
The decision to use Jinja2 for server-side templating and Chart.js for data visualization influences the structure of the frontend code and the way dynamic content is rendered.
|
||||
|
||||
### Simulation Logic
|
||||
|
||||
The Monte Carlo simulation logic must be designed to efficiently handle large datasets and perform computations within the constraints of the chosen programming language (Python) and its libraries.
|
||||
|
||||
## Organizational and Political Constraints
|
||||
|
||||
### Team Expertise
|
||||
|
||||
The development team's familiarity with FastAPI, SQLAlchemy, and frontend technologies like Jinja2 and Chart.js influences the architecture choices to ensure maintainability and ease of development.
|
||||
|
||||
### Development Processes
|
||||
|
||||
The adoption of Agile methodologies and CI/CD pipelines (using Gitea Actions) shapes the architecture to support continuous integration, automated testing, and deployment practices.
|
||||
|
||||
### Collaboration Tools
|
||||
|
||||
The use of specific collaboration and version control tools (e.g., Gitea) affects how code is managed, reviewed, and integrated, impacting the overall architecture and development workflow.
|
||||
|
||||
### Documentation Standards
|
||||
|
||||
The requirement for comprehensive documentation (as seen in the `docs/` folder) necessitates an architecture that is well-structured and easy to understand for both current and future team members.
|
||||
|
||||
### Knowledge Sharing
|
||||
|
||||
The need for effective knowledge sharing and onboarding processes influences the architecture to ensure that it is accessible and understandable for new team members.
|
||||
|
||||
### Resource Availability
|
||||
|
||||
The availability of hardware, software, and human resources within the organization can impose constraints on the architecture, affecting decisions related to scalability, performance, and feature implementation.
|
||||
|
||||
## Regulatory Constraints
|
||||
|
||||
### Data Privacy Compliance
|
||||
|
||||
The architecture must ensure compliance with data privacy regulations such as GDPR or CCPA, which may dictate how user data is collected, stored, and processed.
|
||||
|
||||
### Industry Standards
|
||||
|
||||
Adherence to industry-specific standards and best practices may influence the design of data models, security measures, and reporting functionalities.
|
||||
|
||||
### Auditability
|
||||
|
||||
The system may need to incorporate logging and auditing features to meet regulatory requirements, affecting the architecture of data storage and access controls.
|
||||
|
||||
### Data Retention Policies
|
||||
|
||||
Regulatory requirements regarding data retention and deletion may impose constraints on how long certain types of data can be stored, influencing database design and data lifecycle management.
|
||||
|
||||
### Security Standards
|
||||
|
||||
Compliance with security standards (e.g., ISO/IEC 27001) may necessitate the implementation of specific security measures, such as encryption, access controls, and vulnerability management, which impact the overall architecture.
|
||||
|
||||
## Environmental Constraints
|
||||
|
||||
### Deployment Environments
|
||||
|
||||
The architecture must accommodate various deployment environments (development, testing, production) with differing configurations and resource allocations.
|
||||
|
||||
### Cloud Provider Limitations
|
||||
|
||||
If deployed on a specific cloud provider, the architecture may need to align with the provider's services, limitations, and best practices, such as using managed databases or specific container orchestration tools.
|
||||
|
||||
### Containerization
|
||||
|
||||
The use of Docker for containerization imposes constraints on how the application is packaged, deployed, and scaled, influencing the architecture to ensure compatibility with container orchestration platforms.
|
||||
|
||||
### Scalability Requirements
|
||||
|
||||
The architecture must be designed to scale efficiently based on anticipated load and usage patterns, considering the limitations of the chosen infrastructure.
|
||||
|
||||
## Performance Constraints
|
||||
|
||||
### Response Time
|
||||
|
||||
The system must ensure that user interactions, such as data retrieval and report generation, occur within acceptable time frames to maintain a positive user experience.
|
||||
|
||||
### Scalability Needs
|
||||
|
||||
The architecture should support scaling to accommodate varying workloads, ensuring consistent performance during peak usage periods without significant degradation.
|
||||
|
||||
## Conventions
|
||||
|
||||
### Programming Language
|
||||
|
||||
The system is developed using Python, and all code must adhere to PEP 8 style guidelines to ensure consistency and readability across the codebase.
|
||||
|
||||
### Versioning
|
||||
|
||||
Semantic Versioning (SemVer) is used for all releases to clearly communicate changes and compatibility.
|
||||
130
architecture/03_context_and_scope.md
Normal file
130
architecture/03_context_and_scope.md
Normal file
@@ -0,0 +1,130 @@
|
||||
# Context and Scope
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Context and Scope](#context-and-scope)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Business Context](#business-context)
|
||||
- [Users](#users)
|
||||
- [Systems](#systems)
|
||||
- [Technical Context](#technical-context)
|
||||
- [Communication Channels and Protocols](#communication-channels-and-protocols)
|
||||
|
||||
## Business Context
|
||||
|
||||
The business context for the system includes various stakeholders such as end-users, business analysts, and regulatory bodies. Each of these stakeholders has specific needs and expectations regarding the system's functionality and data handling.
|
||||
|
||||
### Users
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
User[Users]
|
||||
System[System]
|
||||
System -->|Outputs| User
|
||||
User -->|Inputs| System
|
||||
```
|
||||
|
||||
- Executive Management: Reviews high-level reports generated by the system for strategic planning.
|
||||
- Project Managers: Use the system to plan projects and monitor progress.
|
||||
- Business Analysts: Utilize system outputs for decision-making and strategy formulation.
|
||||
- Financial Analysts: Analyze financial data produced by the system to guide investment decisions.
|
||||
- Administrators: Manage system configurations and user access.
|
||||
- DevOps: Oversee deployment and integration processes, ensuring system reliability and performance.
|
||||
|
||||
| User | Inputs | Outputs |
|
||||
| -------------------- | ----------------------- | -------------------------- |
|
||||
| Executive Management | Strategic data requests | High-level reports |
|
||||
| Project Managers | Project plans | Progress updates |
|
||||
| Business Analysts | Data queries | Analytical insights |
|
||||
| Financial Analysts | Financial data | Investment reports |
|
||||
| Administrators | Configuration changes | System status |
|
||||
| DevOps | Deployment scripts | System performance metrics |
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph CalMiner
|
||||
System[System]
|
||||
end
|
||||
EM[Executive Management]
|
||||
PM[Project Managers]
|
||||
BA[Business Analysts]
|
||||
FA[Financial Analysts]
|
||||
|
||||
EM -->|Strategic data requests| System
|
||||
System -->|High-level reports| EM
|
||||
|
||||
PM -->|Project plans| System
|
||||
System -->|Progress updates| PM
|
||||
|
||||
BA -->|Data queries| System
|
||||
System -->|Analytical insights| BA
|
||||
|
||||
FA -->|Financial data| System
|
||||
System -->|Investment reports| FA
|
||||
|
||||
```
|
||||
|
||||
### Systems
|
||||
|
||||
- Database Systems: Store and retrieve data used and generated by the system.
|
||||
- Data Warehouse: Provides historical data for analysis and reporting.
|
||||
- External APIs: Supplies real-time data inputs for scenario analysis.
|
||||
- Authentication Service: Manages user authentication and authorization.
|
||||
- Reporting Tools: Integrates with the system to generate customized reports.
|
||||
- Monitoring Systems: Tracks system performance and health metrics.
|
||||
- CI/CD Pipeline: Facilitates automated deployment and integration processes.
|
||||
- Logging Service: Collects and stores system logs for auditing and troubleshooting purposes.
|
||||
- Backup System: Ensures data integrity and recovery in case of failures.
|
||||
- Notification Service: Sends alerts and notifications to users based on system events.
|
||||
|
||||
| Systems | Inputs | Outputs |
|
||||
| ---------------------- | -------------------------- | --------------------- |
|
||||
| Database Systems | Data read/write requests | Stored/retrieved data |
|
||||
| Data Warehouse | Historical data queries | Historical datasets |
|
||||
| External APIs | Real-time data requests | Real-time data feeds |
|
||||
| Authentication Service | Login requests | Authentication tokens |
|
||||
| Reporting Tools | Report generation requests | Customized reports |
|
||||
| Monitoring Systems | Performance data | Health metrics |
|
||||
| CI/CD Pipeline | Code commits | Deployed applications |
|
||||
| Logging Service | Log entries | Stored logs |
|
||||
| Backup System | Backup requests | Restored data |
|
||||
| Notification Service | Alert triggers | User notifications |
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph CalMiner
|
||||
System[System]
|
||||
end
|
||||
DB[Database Systems]
|
||||
DW[Data Warehouse]
|
||||
API[External APIs]
|
||||
Auth[Authentication Service]
|
||||
|
||||
DB -->|Data read/write requests| System
|
||||
System -->|Stored/retrieved data| DB
|
||||
|
||||
DW -->|Historical data queries| System
|
||||
System -->|Historical datasets| DW
|
||||
|
||||
API -->|Real-time data requests| System
|
||||
System -->|Real-time data feeds| API
|
||||
|
||||
Auth -->|Login requests| System
|
||||
System -->|Authentication tokens| Auth
|
||||
|
||||
```
|
||||
|
||||
## Technical Context
|
||||
|
||||
### Communication Channels and Protocols
|
||||
|
||||
| Communication Partner | Channel/Protocol | Description |
|
||||
| ---------------------- | ------------------ | ------------------------------------------------- |
|
||||
| Database Systems | TCP/IP, SQL | Standard database communication protocols |
|
||||
| Data Warehouse | ODBC/JDBC | Database connectivity protocols |
|
||||
| External APIs | RESTful HTTP, JSON | Web service communication protocols |
|
||||
| Authentication Service | OAuth 2.0, HTTPS | Secure authentication and authorization protocols |
|
||||
| Reporting Tools | HTTP, PDF/Excel | Report generation and delivery protocols |
|
||||
| Monitoring Systems | SNMP, HTTP | System monitoring and alerting protocols |
|
||||
| CI/CD Pipeline | Git, SSH | Code versioning and deployment protocols |
|
||||
| Notification Service | SMTP, Webhooks | Alert and notification delivery protocols |
|
||||
83
architecture/04_solution_strategy.md
Normal file
83
architecture/04_solution_strategy.md
Normal file
@@ -0,0 +1,83 @@
|
||||
# Solution Strategy
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Solution Strategy](#solution-strategy)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Technology Decisions](#technology-decisions)
|
||||
- [Programming Language](#programming-language)
|
||||
- [Web Framework](#web-framework)
|
||||
- [Database](#database)
|
||||
- [Frontend Technologies](#frontend-technologies)
|
||||
- [Architectural Patterns](#architectural-patterns)
|
||||
- [Layered Architecture](#layered-architecture)
|
||||
- [Client-Server Pattern](#client-server-pattern)
|
||||
- [Containerization](#containerization)
|
||||
- [Quality Goals Achievement](#quality-goals-achievement)
|
||||
- [Comprehensive Scenario Analysis](#comprehensive-scenario-analysis)
|
||||
- [Data-Driven Decision Making](#data-driven-decision-making)
|
||||
- [User-Friendly Interface](#user-friendly-interface)
|
||||
- [Security](#security)
|
||||
- [Scalability](#scalability)
|
||||
- [Organizational Decisions](#organizational-decisions)
|
||||
- [Development Process](#development-process)
|
||||
|
||||
## Technology Decisions
|
||||
|
||||
### Programming Language
|
||||
|
||||
Python as the primary programming language for its simplicity, readability, and extensive libraries that support rapid development and data analysis.
|
||||
|
||||
### Web Framework
|
||||
|
||||
FastAPI as the web framework due to its high performance, ease of use, and support for asynchronous programming, which is essential for handling multiple concurrent requests efficiently.
|
||||
|
||||
### Database
|
||||
|
||||
PostgreSQL as the database system for its robustness, scalability, and strong support for complex queries, which are necessary for managing the application's data effectively.
|
||||
|
||||
### Frontend Technologies
|
||||
|
||||
Jinja2 for server-side templating to dynamically generate HTML pages, and Chart.js for data visualization to provide interactive charts and graphs for users.
|
||||
|
||||
## Architectural Patterns
|
||||
|
||||
### Layered Architecture
|
||||
|
||||
The system follows a layered architecture pattern, separating concerns into distinct layers: presentation, business logic, and data access. This separation enhances maintainability, scalability, and testability of the application.
|
||||
|
||||
### Client-Server Pattern
|
||||
|
||||
The application is designed using the client-server pattern, where the client (frontend) interacts with the server (backend) through RESTful APIs. This separation allows for independent development and scaling of the client and server components.
|
||||
|
||||
### Containerization
|
||||
|
||||
The application is containerized using Docker or podman to ensure consistency across different deployment environments, facilitate scalability, and simplify the deployment process.
|
||||
|
||||
## Quality Goals Achievement
|
||||
|
||||
### Comprehensive Scenario Analysis
|
||||
|
||||
The system employs efficient data processing algorithms and leverages PostgreSQL's capabilities to handle large datasets, enabling users to create and analyze multiple project scenarios effectively.
|
||||
|
||||
### Data-Driven Decision Making
|
||||
|
||||
Stakeholders have access to real-time data and analytics to inform their decisions.
|
||||
|
||||
### User-Friendly Interface
|
||||
|
||||
The platform is designed with an intuitive interface that requires minimal training for new users.
|
||||
|
||||
### Security
|
||||
|
||||
Sensitive data is protected through robust security measures, including encryption and access controls.
|
||||
|
||||
### Scalability
|
||||
|
||||
The system is designed to scale horizontally by adding more instances of services as needed. This is facilitated by the use of containerization and orchestration tools like Kubernetes, which manage the deployment and scaling of containerized applications.
|
||||
|
||||
## Organizational Decisions
|
||||
|
||||
### Development Process
|
||||
|
||||
The development team follows an Agile methodology, allowing for iterative development, continuous feedback, and adaptability to changing requirements. This approach enhances collaboration among team members and stakeholders, ensuring that the final product meets user needs effectively.
|
||||
221
architecture/05_building_block_view.md
Normal file
221
architecture/05_building_block_view.md
Normal file
@@ -0,0 +1,221 @@
|
||||
# Building Block View
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Building Block View](#building-block-view)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Whitebox Overall System](#whitebox-overall-system)
|
||||
- [Level 1 Diagram](#level-1-diagram)
|
||||
- [API Layer](#api-layer)
|
||||
- [Service Layer](#service-layer)
|
||||
- [Data Access Layer](#data-access-layer)
|
||||
- [Frontend Layer](#frontend-layer)
|
||||
- [Database System](#database-system)
|
||||
- [Level 2](#level-2)
|
||||
- [Level 2 Diagram](#level-2-diagram)
|
||||
- [Frontend Components](#frontend-components)
|
||||
- [User Interface](#user-interface)
|
||||
- [Visualization Module](#visualization-module)
|
||||
- [Backend Components](#backend-components)
|
||||
- [Authentication Service](#authentication-service)
|
||||
- [Reporting Module](#reporting-module)
|
||||
- [Simulation Engine](#simulation-engine)
|
||||
- [Level 3](#level-3)
|
||||
- [Simulation Engine Components](#simulation-engine-components)
|
||||
- [Mining Algorithm](#mining-algorithm)
|
||||
- [Data Preprocessing](#data-preprocessing)
|
||||
- [Result Postprocessing](#result-postprocessing)
|
||||
|
||||
## Whitebox Overall System
|
||||
|
||||
This diagram shows the main building blocks of the Calminer system and their relationships.
|
||||
|
||||
### Level 1 Diagram
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
APILayer[API Layer]
|
||||
ServiceLayer[Service Layer]
|
||||
DataAccessLayer[Data Access Layer]
|
||||
FrontendLayer[Frontend Layer]
|
||||
DatabaseSystem[Database System]
|
||||
|
||||
APILayer --> ServiceLayer
|
||||
ServiceLayer --> DataAccessLayer
|
||||
FrontendLayer --> APILayer
|
||||
DataAccessLayer --> DatabaseSystem
|
||||
```
|
||||
|
||||
### API Layer
|
||||
|
||||
The API Layer is responsible for handling incoming requests and routing them to the appropriate services. It provides a RESTful interface for external clients to interact with the Calminer system.
|
||||
|
||||
_Responsibility:_ Handle HTTP requests and responses.
|
||||
|
||||
_Interface:_ RESTful API endpoints.
|
||||
|
||||
_Dependencies:_ Depends on the Service Layer for business logic processing.
|
||||
|
||||
### Service Layer
|
||||
|
||||
The Service Layer contains the core business logic of the Calminer application. It processes data, applies mining algorithms, and manages workflows between different components.
|
||||
|
||||
_Responsibility:_ Implement business rules and data processing.
|
||||
|
||||
_Interface:_ Service interfaces for communication with the API Layer.
|
||||
|
||||
_Dependencies:_ Depends on the Data Access Layer for data persistence.
|
||||
|
||||
### Data Access Layer
|
||||
|
||||
The Data Access Layer is responsible for interacting with the underlying data storage systems. It provides an abstraction over the data sources and handles all CRUD operations.
|
||||
|
||||
_Responsibility:_ Manage data storage and retrieval.
|
||||
|
||||
_Interface:_ Data access interfaces for the Service Layer.
|
||||
|
||||
_Dependencies:_ Depends on the Database System for persistent storage.
|
||||
|
||||
### Frontend Layer
|
||||
|
||||
The Frontend Layer is responsible for the user interface of the Calminer application. It provides a web-based interface for users to create projects, configure parameters, and view reports.
|
||||
|
||||
_Responsibility:_ Render user interface and handle user interactions.
|
||||
|
||||
_Interface:_ Web pages and client-side scripts.
|
||||
|
||||
_Dependencies:_ Depends on the API Layer for backend communication.
|
||||
|
||||
### Database System
|
||||
|
||||
The Database System is responsible for storing and managing all persistent data used by the Calminer application, including user data, project configurations, and analysis results.
|
||||
|
||||
_Responsibility:_ Manage persistent data storage and retrieval.
|
||||
|
||||
_Interface:_ Database access interfaces for the Data Access Layer.
|
||||
|
||||
_Dependencies:_ None.
|
||||
|
||||
## Level 2
|
||||
|
||||
### Level 2 Diagram
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
subgraph F[Frontend Layer]
|
||||
direction TB
|
||||
UserInterface[User Interface]
|
||||
VisualizationModule[Visualization Module]
|
||||
end
|
||||
subgraph A[API Layer]
|
||||
APILayer[API Layer]
|
||||
end
|
||||
subgraph S[Service Layer]
|
||||
direction TB
|
||||
AuthenticationService[Authentication Service]
|
||||
ReportingModule[Reporting Module]
|
||||
SimulationEngine[Simulation Engine]
|
||||
end
|
||||
subgraph D[Data Access Layer]
|
||||
DataAccessLayer[Data Access Layer]
|
||||
end
|
||||
subgraph DB[Database System]
|
||||
DatabaseSystem[Database System]
|
||||
end
|
||||
|
||||
DataAccessLayer[Data Access Layer]
|
||||
DatabaseSystem[Database System]
|
||||
|
||||
F --> A
|
||||
A --> S
|
||||
S --> D
|
||||
D --> DB
|
||||
```
|
||||
|
||||
### Frontend Components
|
||||
|
||||
#### User Interface
|
||||
|
||||
The User Interface component is responsible for rendering the web pages and handling user interactions.
|
||||
|
||||
_Responsibility:_ Display data and capture user input.
|
||||
|
||||
_Interface:_ HTML, CSS, JavaScript.
|
||||
|
||||
_Dependencies:_ Depends on the API Layer for data retrieval.
|
||||
|
||||
#### Visualization Module
|
||||
|
||||
The Visualization Module provides data visualization capabilities, allowing users to view analysis results in graphical formats.
|
||||
|
||||
_Responsibility:_ Generate charts and graphs.
|
||||
|
||||
_Interface:_ Chart.js library.
|
||||
|
||||
_Dependencies:_ Depends on the API Layer for data.
|
||||
|
||||
### Backend Components
|
||||
|
||||
#### Authentication Service
|
||||
|
||||
The Authentication Service manages user authentication and authorization.
|
||||
|
||||
_Responsibility:_ Handle user login and access control.
|
||||
|
||||
_Interface:_ Authentication APIs.
|
||||
|
||||
_Dependencies:_ Depends on the Database System for user data.
|
||||
|
||||
#### Reporting Module
|
||||
|
||||
The Reporting Module generates comprehensive reports based on analysis results.
|
||||
|
||||
_Responsibility:_ Create and format reports.
|
||||
|
||||
_Interface:_ Report generation APIs.
|
||||
|
||||
_Dependencies:_ Depends on the Service Layer for data processing.
|
||||
|
||||
#### Simulation Engine
|
||||
|
||||
The Simulation Engine performs the core mining simulations and calculations.
|
||||
|
||||
_Responsibility:_ Execute mining algorithms.
|
||||
|
||||
_Interface:_ Simulation APIs.
|
||||
|
||||
_Dependencies:_ Depends on the Data Access Layer for data retrieval and storage.
|
||||
|
||||
## Level 3
|
||||
|
||||
### Simulation Engine Components
|
||||
|
||||
#### Mining Algorithm
|
||||
|
||||
The Mining Algorithm component is responsible for implementing the core mining logic.
|
||||
|
||||
_Responsibility:_ Execute mining algorithms on the input data.
|
||||
|
||||
_Interface:_ Algorithm APIs.
|
||||
|
||||
_Dependencies:_ Depends on the Data Access Layer for data retrieval.
|
||||
|
||||
#### Data Preprocessing
|
||||
|
||||
The Data Preprocessing component handles the preparation of input data for mining.
|
||||
|
||||
_Responsibility:_ Clean and transform input data.
|
||||
|
||||
_Interface:_ Data preprocessing APIs.
|
||||
|
||||
_Dependencies:_ Depends on the Data Access Layer for data retrieval.
|
||||
|
||||
#### Result Postprocessing
|
||||
|
||||
The Result Postprocessing component is responsible for formatting and refining the mining results.
|
||||
|
||||
_Responsibility:_ Prepare final results for presentation.
|
||||
|
||||
_Interface:_ Result formatting APIs.
|
||||
|
||||
_Dependencies:_ Depends on the Data Access Layer for data storage.
|
||||
346
architecture/06_runtime_view.md
Normal file
346
architecture/06_runtime_view.md
Normal file
@@ -0,0 +1,346 @@
|
||||
# Runtime View
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Runtime View](#runtime-view)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Login Process](#login-process)
|
||||
- [Project Creation](#project-creation)
|
||||
- [Mining Method Selection](#mining-method-selection)
|
||||
- [Scenario Creation](#scenario-creation)
|
||||
- [Default Business Scenario](#default-business-scenario)
|
||||
- [Parameter Configuration](#parameter-configuration)
|
||||
- [Basic Accounting Setup](#basic-accounting-setup)
|
||||
- [Currency Setup](#currency-setup)
|
||||
- [Report Generation](#report-generation)
|
||||
- [User Management](#user-management)
|
||||
|
||||
<!--
|
||||
The runtime view describes concrete behavior and interactions of the system's building blocks in form of scenarios from the following areas:
|
||||
|
||||
- important use cases or features: how do building blocks execute them?
|
||||
- interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?
|
||||
- operation and administration: launch, start-up, stop
|
||||
- error and exception scenarios
|
||||
|
||||
Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their _architectural relevance_. It is _not_ important to describe a large number of scenarios. You should rather document a representative selection.
|
||||
|
||||
_Motivation:_ You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).
|
||||
|
||||
_Form:_ There are many notations for describing scenarios, e.g. numbered list of steps (in natural language), activity diagrams or flow charts, sequence diagrams, BPMN or EPCs (event process chains), state machines, ...
|
||||
|
||||
## Runtime Scenario 1
|
||||
|
||||
- _<insert runtime diagram or textual description of the scenario>_
|
||||
- _<insert description of the notable aspects of the interactions between the building block instances depicted in this diagram.>_
|
||||
|
||||
-->
|
||||
|
||||
## Login Process
|
||||
|
||||
1. The user navigates to the login page.
|
||||
2. The user enters their credentials (username and password).
|
||||
3. The API Layer receives the login request and forwards it to the Authentication Service in the Service Layer.
|
||||
4. The Authentication Service validates the credentials against the user data stored in the Database System via the Data Access Layer.
|
||||
5. If the credentials are valid, the Authentication Service generates a session token and sends it back to the API Layer.
|
||||
6. The API Layer returns the session token to the user, granting access to the system.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant U as User
|
||||
participant API as API Layer
|
||||
participant AS as Authentication Service
|
||||
participant DB as Database System
|
||||
|
||||
U->>API: Submit login credentials
|
||||
API->>AS: Forward credentials
|
||||
AS->>DB: Validate credentials
|
||||
DB-->>AS: Return validation result
|
||||
alt Valid Credentials
|
||||
AS->>API: Generate session token
|
||||
API->>U: Return session token
|
||||
else Invalid Credentials
|
||||
AS->>API: Return error message
|
||||
API->>U: Return error message
|
||||
end
|
||||
```
|
||||
|
||||
## Project Creation
|
||||
|
||||
### Mining Method Selection
|
||||
|
||||
1. The user selects the option to create a new project.
|
||||
2. The API Layer presents the user with a list of available mining methods.
|
||||
3. The user selects a mining method from the list.
|
||||
4. The API Layer forwards the selection to the Service Layer.
|
||||
5. The Service Layer retrieves the details of the selected mining method from the Data Access Layer.
|
||||
6. The Data Access Layer queries the Database System for the mining method information.
|
||||
7. The Database System returns the mining method details to the Data Access Layer.
|
||||
8. The Data Access Layer sends the mining method details back to the Service Layer.
|
||||
9. The Service Layer returns the mining method details to the API Layer.
|
||||
10. The API Layer displays the mining method details to the user for confirmation.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant U as User
|
||||
participant API as API Layer
|
||||
participant S as Service Layer
|
||||
participant D as Data Access Layer
|
||||
|
||||
U->>API: Select mining method
|
||||
API->>S: Forward selection
|
||||
S->>D: Retrieve available methods
|
||||
D-->>S: Return methods
|
||||
S-->>API: Return methods
|
||||
API->>U: Display methods
|
||||
U->>API: Confirm selection
|
||||
API->>S: Forward confirmation
|
||||
S->>D: Store selected method
|
||||
D-->>S: Acknowledge storage
|
||||
```
|
||||
|
||||
## Scenario Creation
|
||||
|
||||
### Default Business Scenario
|
||||
|
||||
1. The user selects the option to create a default business scenario.
|
||||
2. The API Layer receives the request and forwards it to the Service Layer.
|
||||
3. The Service Layer initiates the creation of a default scenario in the Data Access Layer.
|
||||
4. The Data Access Layer creates the default scenario in the Database System.
|
||||
5. The Database System acknowledges the creation of the scenario to the Data Access Layer.
|
||||
6. The Data Access Layer confirms the scenario creation to the Service Layer.
|
||||
7. The Service Layer notifies the API Layer of the successful scenario creation.
|
||||
8. The API Layer informs the user that the default business scenario has been successfully created.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant U as User
|
||||
participant API as API Layer
|
||||
participant S as Service Layer
|
||||
participant D as Data Access Layer
|
||||
|
||||
U->>API: Request default scenario creation
|
||||
API->>S: Forward request
|
||||
S->>D: Create default scenario
|
||||
D-->>S: Acknowledge creation
|
||||
S-->>API: Confirm scenario creation
|
||||
API->>U: Notify user of successful creation
|
||||
```
|
||||
|
||||
## Parameter Configuration
|
||||
|
||||
1. The user navigates to the parameter configuration section.
|
||||
2. The API Layer retrieves the current configuration parameters from the Service Layer.
|
||||
3. The Service Layer requests the parameters from the Data Access Layer.
|
||||
4. The Data Access Layer queries the Database System for the configuration parameters.
|
||||
5. The Database System returns the configuration parameters to the Data Access Layer.
|
||||
6. The Data Access Layer sends the parameters back to the Service Layer.
|
||||
7. The Service Layer forwards the parameters to the API Layer.
|
||||
8. The API Layer displays the current configuration parameters to the user.
|
||||
9. The user modifies the desired parameters and submits the changes.
|
||||
10. The API Layer forwards the updated parameters to the Service Layer.
|
||||
11. The Service Layer updates the parameters in the Data Access Layer.
|
||||
12. The Data Access Layer saves the updated parameters in the Database System.
|
||||
13. The Database System acknowledges the update to the Data Access Layer.
|
||||
14. The Data Access Layer confirms the update to the Service Layer.
|
||||
15. The Service Layer notifies the API Layer of the successful parameter update.
|
||||
16. The API Layer informs the user that the parameters have been successfully updated.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant U as User
|
||||
participant API as API Layer
|
||||
participant S as Service Layer
|
||||
participant D as Data Access Layer
|
||||
participant DB as Database System
|
||||
|
||||
U->>API: Request current parameters
|
||||
API->>S: Forward request
|
||||
S->>D: Retrieve parameters
|
||||
D->>DB: Query parameters
|
||||
DB-->>D: Return parameters
|
||||
D-->>S: Send parameters
|
||||
S-->>API: Forward parameters
|
||||
API->>U: Display parameters
|
||||
U->>API: Submit updated parameters
|
||||
API->>S: Forward updates
|
||||
S->>D: Update parameters
|
||||
D->>DB: Save updated parameters
|
||||
DB-->>D: Acknowledge update
|
||||
D-->>S: Confirm update
|
||||
S-->>API: Notify successful update
|
||||
API->>U: Inform user of success
|
||||
```
|
||||
|
||||
## Basic Accounting Setup
|
||||
|
||||
1. The user accesses the basic accounting setup section.
|
||||
2. The API Layer retrieves the current accounting settings from the Service Layer.
|
||||
3. The Service Layer requests the settings from the Data Access Layer.
|
||||
4. The Data Access Layer queries the Database System for the accounting settings.
|
||||
5. The Database System returns the accounting settings to the Data Access Layer.
|
||||
6. The Data Access Layer sends the settings back to the Service Layer.
|
||||
7. The Service Layer forwards the settings to the API Layer.
|
||||
8. The API Layer displays the current accounting settings to the user.
|
||||
9. The user modifies the accounting settings and submits the changes.
|
||||
10. The API Layer forwards the updated settings to the Service Layer.
|
||||
11. The Service Layer updates the settings in the Data Access Layer.
|
||||
12. The Data Access Layer saves the updated settings in the Database System.
|
||||
13. The Database System acknowledges the update to the Data Access Layer.
|
||||
14. The Data Access Layer confirms the update to the Service Layer.
|
||||
15. The Service Layer notifies the API Layer of the successful accounting settings update.
|
||||
16. The API Layer informs the user that the accounting settings have been successfully updated.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant U as User
|
||||
participant API as API Layer
|
||||
participant S as Service Layer
|
||||
participant D as Data Access Layer
|
||||
participant DB as Database System
|
||||
|
||||
U->>API: Request current accounting settings
|
||||
API->>S: Forward request
|
||||
S->>D: Retrieve settings
|
||||
D->>DB: Query settings
|
||||
DB-->>D: Return settings
|
||||
D-->>S: Send settings
|
||||
S-->>API: Forward settings
|
||||
API->>U: Display settings
|
||||
U->>API: Submit updated settings
|
||||
API->>S: Forward updates
|
||||
S->>D: Update settings
|
||||
D->>DB: Save updated settings
|
||||
DB-->>D: Acknowledge update
|
||||
D-->>S: Confirm update
|
||||
S-->>API: Notify successful update
|
||||
API->>U: Inform user of success
|
||||
```
|
||||
|
||||
## Currency Setup
|
||||
|
||||
1. The user navigates to the currency setup section.
|
||||
2. The API Layer retrieves the current currency settings from the Service Layer.
|
||||
3. The Service Layer requests the settings from the Data Access Layer.
|
||||
4. The Data Access Layer queries the Database System for the currency settings.
|
||||
5. The Database System returns the currency settings to the Data Access Layer.
|
||||
6. The Data Access Layer sends the settings back to the Service Layer.
|
||||
7. The Service Layer forwards the settings to the API Layer.
|
||||
8. The API Layer displays the current currency settings to the user.
|
||||
9. The user modifies the currency settings and submits the changes.
|
||||
10. The API Layer forwards the updated settings to the Service Layer.
|
||||
11. The Service Layer updates the settings in the Data Access Layer.
|
||||
12. The Data Access Layer saves the updated settings in the Database System.
|
||||
13. The Database System acknowledges the update to the Data Access Layer.
|
||||
14. The Data Access Layer confirms the update to the Service Layer.
|
||||
15. The Service Layer notifies the API Layer of the successful currency settings update.
|
||||
16. The API Layer informs the user that the currency settings have been successfully updated.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant U as User
|
||||
participant API as API Layer
|
||||
participant S as Service Layer
|
||||
participant D as Data Access Layer
|
||||
participant DB as Database System
|
||||
|
||||
U->>API: Request current currency settings
|
||||
API->>S: Forward request
|
||||
S->>D: Retrieve settings
|
||||
D->>DB: Query settings
|
||||
DB-->>D: Return settings
|
||||
D-->>S: Send settings
|
||||
S-->>API: Forward settings
|
||||
API->>U: Display settings
|
||||
U->>API: Submit updated settings
|
||||
API->>S: Forward updates
|
||||
S->>D: Update settings
|
||||
D->>DB: Save updated settings
|
||||
DB-->>D: Acknowledge update
|
||||
D-->>S: Confirm update
|
||||
S-->>API: Notify successful update
|
||||
API->>U: Inform user of success
|
||||
```
|
||||
|
||||
## Report Generation
|
||||
|
||||
1. The user selects the option to generate a report.
|
||||
2. The API Layer receives the report generation request and forwards it to the Reporting Module in the Service Layer.
|
||||
3. The Reporting Module retrieves the necessary data from the Data Access Layer.
|
||||
4. The Data Access Layer queries the Database System for the required data.
|
||||
5. The Database System returns the data to the Data Access Layer.
|
||||
6. The Data Access Layer sends the data back to the Reporting Module.
|
||||
7. The Reporting Module processes the data and generates the report.
|
||||
8. The Reporting Module returns the generated report to the API Layer.
|
||||
9. The API Layer delivers the report to the user for download or viewing.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant U as User
|
||||
participant API as API Layer
|
||||
participant S as Service Layer
|
||||
participant D as Data Access Layer
|
||||
participant DB as Database System
|
||||
|
||||
U->>API: Request report generation
|
||||
API->>S: Forward request
|
||||
S->>D: Retrieve data for report
|
||||
D->>DB: Query data
|
||||
DB-->>D: Return data
|
||||
D-->>S: Send data
|
||||
S-->>API: Forward data
|
||||
API->>U: Display report
|
||||
```
|
||||
|
||||
## User Management
|
||||
|
||||
1. The user navigates to the user management section.
|
||||
2. The API Layer retrieves the list of users from the Service Layer.
|
||||
3. The Service Layer requests the user list from the Data Access Layer.
|
||||
4. The Data Access Layer queries the Database System for the user information.
|
||||
5. The Database System returns the user information to the Data Access Layer.
|
||||
6. The Data Access Layer sends the user information back to the Service Layer.
|
||||
7. The Service Layer forwards the user information to the API Layer.
|
||||
8. The API Layer displays the list of users to the administrator.
|
||||
9. The administrator can add, modify, or delete users as needed.
|
||||
10. The API Layer forwards any user management actions to the Service Layer.
|
||||
11. The Service Layer processes the actions in the Data Access Layer.
|
||||
12. The Data Access Layer updates the user information in the Database System.
|
||||
13. The Database System acknowledges the updates to the Data Access Layer.
|
||||
14. The Data Access Layer confirms the updates to the Service Layer.
|
||||
15. The Service Layer notifies the API Layer of the successful user management actions.
|
||||
16. The API Layer informs the administrator of the successful user management operations.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant U as User
|
||||
participant API as API Layer
|
||||
participant S as Service Layer
|
||||
participant D as Data Access Layer
|
||||
participant DB as Database System
|
||||
|
||||
U->>API: Request user information
|
||||
API->>S: Forward request
|
||||
S->>D: Retrieve user data
|
||||
D->>DB: Query user data
|
||||
DB-->>D: Return user data
|
||||
D-->>S: Send user data
|
||||
S-->>API: Forward user data
|
||||
API->>U: Display user information
|
||||
U->>API: Submit user management actions
|
||||
API->>S: Forward actions
|
||||
S->>D: Process user management actions
|
||||
D->>DB: Update user information
|
||||
DB-->>D: Acknowledge updates
|
||||
D-->>S: Confirm updates
|
||||
S-->>API: Notify successful actions
|
||||
API->>U: Inform user of success
|
||||
```
|
||||
120
architecture/07_deployment_view.md
Normal file
120
architecture/07_deployment_view.md
Normal file
@@ -0,0 +1,120 @@
|
||||
# Deployment View
|
||||
|
||||
<!--
|
||||
The deployment view describes:
|
||||
|
||||
1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and
|
||||
|
||||
2. mapping of (software) building blocks to that infrastructure elements.
|
||||
|
||||
Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.
|
||||
|
||||
Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.
|
||||
|
||||
From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture.
|
||||
|
||||
_Motivation:_ Software does not run without hardware. This underlying infrastructure can and will influence a system and/or some cross-cutting concepts. Therefore, there is a need to know the infrastructure.
|
||||
|
||||
_Form:_ Maybe a highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section one can zoom into this black box using additional deployment diagrams: UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, when your infrastructure is more complex. When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.
|
||||
|
||||
## Infrastructure Level 1
|
||||
|
||||
Description of the highest level infrastructure.
|
||||
|
||||
## Infrastructure Level 2
|
||||
|
||||
Zoom into level 1.
|
||||
|
||||
## Mapping of Building Blocks to Infrastructure
|
||||
|
||||
Describe how software building blocks are mapped to the infrastructure.
|
||||
-->
|
||||
|
||||
## Infrastructure Overview
|
||||
|
||||
<!--
|
||||
Describe the highest level infrastructure used to execute your system. This may include geographical locations, environments, computers, processors, channels, and network topologies.
|
||||
-->
|
||||
|
||||
Deployment is carried out across multiple environments, including Development, Testing, Staging, and Production. Each environment is hosted on Docker or Podman containers, orchestrated using Gitea Actions for CI/CD pipelines and leveraging coolify for cloud infrastructure management.
|
||||
|
||||
Communication Channels and Protocols are summarized in [Section 3.2 Technical Context](03_context_and_scope.md#technical-context).
|
||||
|
||||
## Mapping of Building Blocks to Infrastructure
|
||||
|
||||
| Building Block | Infrastructure Component |
|
||||
| ---------------------- | ------------------------ |
|
||||
| API Layer | Docker Container |
|
||||
| Service Layer | Docker Container |
|
||||
| Data Access Layer | Docker Container |
|
||||
| Database | Managed Database Service |
|
||||
| Frontend Layer | Docker Container |
|
||||
| Authentication Service | Docker Container |
|
||||
| Reporting Module | Docker Container |
|
||||
| Simulation Engine | Docker Container |
|
||||
| User Interface | Docker Container |
|
||||
| Visualization Module | Docker Container |
|
||||
| Mining Algorithm | Docker Container |
|
||||
| Data Preprocessing | Docker Container |
|
||||
| Result Postprocessing | Docker Container |
|
||||
| Notification Service | Docker Container |
|
||||
| Logging Service | Docker Container |
|
||||
| Monitoring Service | Docker Container |
|
||||
| Caching Layer | Docker Container |
|
||||
| Load Balancer | Docker Container |
|
||||
| API Gateway | Docker Container |
|
||||
| Message Broker | Docker Container |
|
||||
| Configuration Service | Docker Container |
|
||||
| Backup Service | Docker Container |
|
||||
| Analytics Module | Docker Container |
|
||||
| Search Service | Docker Container |
|
||||
| Scheduler Service | Docker Container |
|
||||
| File Storage Service | Docker Container |
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph Infrastructure
|
||||
DC[Docker/Podman Containers]
|
||||
MDS[Managed Database Service]
|
||||
end
|
||||
|
||||
subgraph BuildingBlocks
|
||||
API[API Layer]
|
||||
SVC[Service Layer]
|
||||
DAL[Data Access Layer]
|
||||
DB[Database]
|
||||
FE[Frontend Layer]
|
||||
end
|
||||
|
||||
API --> DC
|
||||
SVC --> DC
|
||||
DAL --> DC
|
||||
DB --> MDS
|
||||
FE --> DC
|
||||
```
|
||||
|
||||
## Level 2
|
||||
|
||||
### Docker/Podman Containers
|
||||
|
||||
The Docker/Podman Containers host various building blocks of the system, including the API Layer, Service Layer, Data Access Layer, Frontend Layer, and other services such as Authentication Service, Reporting Module, and Simulation Engine. Each container is configured to ensure optimal performance and security.
|
||||
|
||||
### Managed Database Service
|
||||
|
||||
The Managed Database Service hosts the PostgreSQL database, which is used for storing and retrieving data used and generated by the system. The service is configured for high availability, backup, and recovery to ensure data integrity.
|
||||
|
||||
## Level 3
|
||||
|
||||
### Calminer Deployment Container
|
||||
|
||||
The Calminer Deployment Container encapsulates the entire application, including all necessary building blocks and dependencies, to ensure consistent deployment across different environments.
|
||||
|
||||
### Building Block to Container Mapping
|
||||
|
||||
| Building Block | Container Component |
|
||||
| ----------------- | ------------------- |
|
||||
| API Layer | Calminer Container |
|
||||
| Service Layer | Calminer Container |
|
||||
| Data Access Layer | Calminer Container |
|
||||
| Database | Database Container |
|
||||
| Frontend Layer | Calminer Container |
|
||||
22
architecture/README.md
Normal file
22
architecture/README.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# Architecture Documentation
|
||||
|
||||
This folder contains the architecture documentation for the Calminer project, following the arc42 template structure.
|
||||
|
||||
## Chapters
|
||||
|
||||
1. [Introduction and Goals](01_introduction_and_goals.md)
|
||||
2. [Architecture Constraints](02_architecture_constraints.md)
|
||||
3. [Context and Scope](03_context_and_scope.md)
|
||||
4. [Solution Strategy](04_solution_strategy.md)
|
||||
5. [Building Block View](05_building_block_view.md)
|
||||
6. [Runtime View](06_runtime_view.md)
|
||||
7. [Deployment View](07_deployment_view.md)
|
||||
8. [Concepts](08_concepts.md)
|
||||
9. [Architecture Decisions](09_architecture_decisions.md)
|
||||
10. [Quality Requirements](10_quality_requirements.md)
|
||||
11. [Technical Risks](11_technical_risks.md)
|
||||
12. [Glossary](12_glossary.md)
|
||||
|
||||
## About
|
||||
|
||||
This documentation is based on the arc42 template for software architecture documentation.
|
||||
26
requirements/FR-001.md
Normal file
26
requirements/FR-001.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Functional Requirement FR-001: Scenario Creation and Management
|
||||
|
||||
## Description
|
||||
|
||||
The system shall provide tools for creating and analyzing mining project scenarios. Users should be able to define various parameters, assumptions, and conditions that affect mining projects. The system should facilitate the management of multiple scenarios, allowing users to compare outcomes and make informed decisions based on scenario analysis.
|
||||
|
||||
## Rationale
|
||||
|
||||
The ability to create and manage scenarios is crucial for effective decision-making in mining projects. By providing robust tools for scenario analysis, the system enables users to explore different possibilities, assess risks, and optimize project outcomes.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Users can create new mining projects by defining key parameters such as name, location, and type of mining operation.
|
||||
- Users can create new mining project scenarios by specifying relevant parameters and conditions.
|
||||
- The system allows users to save, edit, and delete projects and scenarios.
|
||||
- Users can view a list of all created projects and their associated scenarios.
|
||||
- Users can compare multiple scenarios side-by-side to evaluate differences in outcomes.
|
||||
- The system provides visualizations (e.g., charts, graphs) to aid in the analysis.
|
||||
- The user interface is intuitive and user-friendly, allowing users to easily navigate through project and scenario management features.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Integration with data storage systems to save and retrieve project and scenario information.
|
||||
- User authentication and authorization mechanisms to ensure secure access to project data.
|
||||
- Data visualization libraries to support graphical representation of scenario analysis results.
|
||||
- Integration with other functional requirements, such as data import/export and reporting features.
|
||||
25
requirements/FR-002.md
Normal file
25
requirements/FR-002.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Functional Requirement FR-002: Data Import and Export
|
||||
|
||||
## Description
|
||||
|
||||
The system shall provide functionality for importing and exporting data related to mining projects and scenarios. Users should be able to easily transfer data between the system and external sources, such as spreadsheets or databases, to facilitate data analysis and reporting.
|
||||
|
||||
## Rationale
|
||||
|
||||
Data import and export capabilities are essential for integrating the system with other tools and workflows used by mining professionals. By enabling seamless data exchange, the system enhances its usability and supports a wider range of analytical tasks.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Users can import project and scenario data from common file formats (e.g., CSV, Excel).
|
||||
- Users can export project and scenario data to common file formats (e.g., CSV, Excel).
|
||||
- The system validates imported data for completeness and correctness before processing.
|
||||
- Users can map external data fields to internal system fields during the import process.
|
||||
- The system provides clear error messages and guidance for resolving import/export issues.
|
||||
- Users can schedule regular data exports to automate reporting tasks.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Integration with data storage systems to facilitate data import/export operations.
|
||||
- User interface components for file selection and data mapping during import/export.
|
||||
- Data validation libraries to ensure the quality and integrity of imported data.
|
||||
- Integration with other functional requirements, such as scenario management and reporting features.
|
||||
25
requirements/FR-003.md
Normal file
25
requirements/FR-003.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Functional Requirement FR-003: Reporting and Visualization
|
||||
|
||||
## Description
|
||||
|
||||
The system shall provide reporting and visualization capabilities to help users analyze mining project data and scenario outcomes. Users should be able to generate reports and create visual representations of data to support decision-making processes.
|
||||
|
||||
## Rationale
|
||||
|
||||
Effective reporting and visualization are essential for understanding complex data sets and communicating insights to stakeholders. By providing robust reporting tools, the system enables users to extract valuable information and present it in a clear and actionable format.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Users can generate standard reports (e.g., project summaries, scenario comparisons) with customizable parameters.
|
||||
- The system provides a variety of visualization options (e.g., charts, graphs, dashboards) to represent data effectively.
|
||||
- Users can export reports and visualizations in common formats (e.g., PDF, image files).
|
||||
- The system allows users to schedule automated report generation and distribution.
|
||||
- Users can filter and drill down into data within reports and visualizations for deeper analysis.
|
||||
- The reporting interface is user-friendly and supports ad-hoc reporting needs.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Integration with data storage systems to retrieve and process project and scenario data.
|
||||
- Data visualization libraries to support the creation of charts and graphs.
|
||||
- User interface components for report customization and visualization selection.
|
||||
- Integration with other functional requirements, such as data import/export and scenario management features.
|
||||
24
requirements/FR-004.md
Normal file
24
requirements/FR-004.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Functional Requirement FR-004: User Management
|
||||
|
||||
## Description
|
||||
|
||||
The system shall provide user management capabilities to support the administration of user accounts and permissions. Administrators should be able to create, modify, and delete user accounts, as well as assign roles and permissions based on user needs.
|
||||
|
||||
## Rationale
|
||||
|
||||
Effective user management is essential for maintaining the security and integrity of the system. By providing robust user management tools, the system enables administrators to control access to sensitive data and ensure that users have the appropriate permissions to perform their tasks.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Administrators can create new user accounts with relevant details (e.g., name, email, role).
|
||||
- Administrators can modify existing user accounts to update information or change roles.
|
||||
- Administrators can delete user accounts that are no longer needed.
|
||||
- The system supports role-based access control (RBAC) to manage user permissions.
|
||||
- Administrators can view a list of all users and their associated roles and permissions.
|
||||
- The user management interface is user-friendly and supports bulk actions (e.g., bulk user creation, deletion).
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Integration with authentication and authorization mechanisms to enforce user permissions.
|
||||
- User interface components for account management and role assignment.
|
||||
- Integration with other functional requirements, such as data import/export and reporting features.
|
||||
25
requirements/FR-005.md
Normal file
25
requirements/FR-005.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Functional Requirement FR-005: Data Visualization Tools
|
||||
|
||||
## Description
|
||||
|
||||
The system shall provide data visualization tools to help users analyze and interpret mining project data. These tools should enable users to create a variety of visual representations, such as charts, graphs, and dashboards, to facilitate data exploration and insight generation.
|
||||
|
||||
## Rationale
|
||||
|
||||
Data visualization is a critical component of data analysis, as it allows users to identify patterns, trends, and anomalies in complex data sets. By providing robust visualization tools, the system enhances users' ability to make data-driven decisions and communicate findings effectively.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Users can create different types of visualizations (e.g., bar charts, line graphs, pie charts) based on project and scenario data.
|
||||
- The system provides options for customizing visualizations (e.g., colors, labels, data ranges).
|
||||
- Users can save and share visualizations with other stakeholders.
|
||||
- The system supports interactive visualizations that allow users to explore data in real-time (e.g., drill-down capabilities).
|
||||
- Visualizations are responsive and display correctly on various devices (e.g., desktops, tablets, smartphones).
|
||||
- The user interface for creating and managing visualizations is intuitive and user-friendly.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Integration with data storage systems to retrieve and process project and scenario data.
|
||||
- Data visualization libraries to support the creation of charts and graphs.
|
||||
- User interface components for visualization customization and interaction.
|
||||
- Integration with other functional requirements, such as reporting and scenario management features.
|
||||
25
requirements/FR-006.md
Normal file
25
requirements/FR-006.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# Functional Requirement FR-006: System Scalability
|
||||
|
||||
## Description
|
||||
|
||||
The system shall be designed to scale efficiently to accommodate increasing amounts of data and user load. This includes the ability to add resources (e.g., servers, storage) as needed to maintain performance and responsiveness.
|
||||
|
||||
## Rationale
|
||||
|
||||
Scalability is essential for ensuring that the system can grow and adapt to changing demands over time. By building a scalable architecture, the system can support larger datasets, more users, and increased complexity without sacrificing performance.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- The system can handle a specified number of concurrent users without degradation in performance.
|
||||
- The system can process large volumes of data efficiently, with defined performance benchmarks.
|
||||
- The architecture supports horizontal scaling (e.g., adding more servers) and vertical scaling (e.g., upgrading existing hardware).
|
||||
- The system includes monitoring tools to track performance and resource utilization.
|
||||
- The system can automatically adjust resources based on current demand (e.g., auto-scaling).
|
||||
- Documentation is provided to guide administrators in scaling the system effectively.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Cloud infrastructure or on-premises hardware that supports scaling.
|
||||
- Load balancing solutions to distribute user traffic and workload.
|
||||
- Monitoring and analytics tools to track system performance and identify bottlenecks.
|
||||
- Integration with other functional requirements, such as data storage and processing capabilities.
|
||||
24
requirements/FR-007.md
Normal file
24
requirements/FR-007.md
Normal file
@@ -0,0 +1,24 @@
|
||||
# Functional Requirement FR-007: Audit Logging
|
||||
|
||||
## Description
|
||||
|
||||
The system shall provide audit logging capabilities to track user activities and changes made within the system. This includes logging actions such as project creation, scenario modifications, and user management activities. The audit logs should be secure, tamper-proof, and easily accessible for review and analysis.
|
||||
|
||||
## Rationale
|
||||
|
||||
Audit logging is essential for ensuring accountability and transparency within the system. By maintaining a comprehensive record of user activities, the system can support compliance requirements, facilitate troubleshooting, and provide insights into user behavior.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- The system logs all user actions related to project and scenario management (e.g., create, update, delete).
|
||||
- The audit logs include relevant metadata such as user ID, timestamp, and action details.
|
||||
- Administrators can access and review audit logs through a user-friendly interface.
|
||||
- The system supports filtering and searching of audit logs based on various criteria (e.g., user, date range, action type).
|
||||
- Audit logs are stored securely and protected from unauthorized access or tampering.
|
||||
- The system provides options for exporting audit logs in common formats (e.g., CSV, JSON).
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Integration with data storage systems to securely store audit logs.
|
||||
- User interface components for log viewing and analysis.
|
||||
- Integration with authentication and authorization mechanisms to ensure secure access to audit logs.
|
||||
34
requirements/FR-008.md
Normal file
34
requirements/FR-008.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Functional Requirement FR-008: Export Analysis Results
|
||||
|
||||
## Description
|
||||
|
||||
The system shall provide functionality for users to export analysis results in various formats (e.g., CSV, Excel, PDF) to facilitate sharing and further analysis. Users should be able to select specific data sets and customize the export options based on their needs.
|
||||
|
||||
## Priority
|
||||
|
||||
Medium
|
||||
|
||||
## Rationale
|
||||
|
||||
Exporting analysis results in multiple formats is essential for users who need to share findings with stakeholders, integrate data into other tools, or perform additional analysis outside the CalMiner platform. This functionality enhances the usability and flexibility of the system.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Users can select specific data sets for export.
|
||||
- The system supports exporting data in multiple formats (e.g., CSV, Excel, PDF).
|
||||
- Users can customize export options (e.g., file name, data range, included fields).
|
||||
- The export process is efficient and does not impact system performance.
|
||||
- Users receive a notification upon successful export, along with a link to download the file.
|
||||
- The system maintains data integrity and security during the export process.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Integration with data storage systems to retrieve and process data for export.
|
||||
- User interface components for export configuration and progress tracking.
|
||||
- Integration with other functional requirements, such as reporting and data visualization features.
|
||||
|
||||
## Additional Requirements
|
||||
|
||||
- The system should provide a user-friendly interface for configuring export options.
|
||||
- The export functionality should be accessible from relevant areas of the application (e.g., project dashboards, analysis results pages).
|
||||
- The system should log export activities for auditing and monitoring purposes.
|
||||
27
requirements/FR-009.md
Normal file
27
requirements/FR-009.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Functional Requirement FR-009: User-Friendly Web Interface
|
||||
|
||||
## Description
|
||||
|
||||
The system shall provide a user-friendly web interface that enables users to easily navigate, access features, and interact with the system. The interface should be intuitive, responsive, and visually appealing, ensuring a positive user experience across different devices and screen sizes.
|
||||
|
||||
## Rationale
|
||||
|
||||
A user-friendly web interface is essential for maximizing user adoption and satisfaction. By providing an intuitive and accessible interface, the system can accommodate a diverse range of users, including those with varying levels of technical expertise. This functionality enhances the overall usability and effectiveness of the system.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
1. The web interface must be accessible via major web browsers (e.g., Chrome, Firefox, Safari, Edge).
|
||||
2. The interface should be responsive, adapting seamlessly to different screen sizes (desktop, tablet, mobile).
|
||||
3. Navigation should be intuitive, with clear menus, buttons, and links that guide users to key features and functionalities.
|
||||
4. The design should follow modern UI/UX principles, ensuring visual appeal and ease of use.
|
||||
5. User feedback mechanisms (e.g., tooltips, help sections) should be incorporated to assist users in understanding how to use the interface.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Integration with backend services to retrieve and display data.
|
||||
- Compatibility with web technologies (HTML, CSS, JavaScript) and frameworks used in the project.
|
||||
|
||||
## Additional Requirements
|
||||
|
||||
- Compliance with accessibility standards (e.g., WCAG) to ensure the interface is usable by individuals with disabilities.
|
||||
- Support for localization and internationalization to accommodate users from different regions and languages.
|
||||
29
requirements/FR-010.md
Normal file
29
requirements/FR-010.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# Functional Requirement FR-010: Collaboration Features
|
||||
|
||||
## Description
|
||||
|
||||
The system shall provide collaboration features that enable multiple users to work on mining project scenarios simultaneously. This includes real-time editing, commenting, and version control to facilitate teamwork and improve productivity.
|
||||
|
||||
## Rationale
|
||||
|
||||
Collaboration is essential for teams working on complex mining projects, as it allows for diverse input, faster problem-solving, and more effective decision-making. By enabling real-time collaboration, the system can enhance teamwork and improve project outcomes.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
1. Users can invite others to collaborate on a specific project scenario.
|
||||
2. The system supports real-time editing, allowing multiple users to make changes simultaneously.
|
||||
3. Users can leave comments and feedback on specific parts of the scenario.
|
||||
4. The system maintains a version history, allowing users to track changes and revert to previous versions if needed.
|
||||
5. Notifications are sent to users when changes are made to shared scenarios.
|
||||
|
||||
## Dependencies
|
||||
|
||||
- Integration with user authentication and access control mechanisms.
|
||||
- Support for real-time communication technologies (e.g., WebSockets) to enable live collaboration.
|
||||
- Compatibility with version control systems to manage changes and track history.
|
||||
|
||||
## Additional Requirements
|
||||
|
||||
- The collaboration features should be accessible from the main project dashboard.
|
||||
- User roles and permissions should be considered when implementing collaboration features.
|
||||
- The system should provide a user-friendly interface for managing collaboration settings and viewing activity history.
|
||||
26
requirements/requirements.md
Normal file
26
requirements/requirements.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
version: 1.0
|
||||
date: 2025-11-07
|
||||
status: draft
|
||||
---
|
||||
|
||||
# Functional Requirements
|
||||
|
||||
This document outlines the key functional requirements for the CalMiner project. These requirements define the essential features and capabilities that the system must provide to meet the needs of its stakeholders.
|
||||
|
||||
## Key Functional Requirements
|
||||
|
||||
| Requirement ID | Description | Priority | Source/Reference |
|
||||
| -------------- | ------------------------------------------------------------------------------------- | -------- | ----------------------------------- |
|
||||
| FR-001 | Provide tools for creating and analyzing mining project scenarios. | High | [FR-001](../requirements/FR-001.md) |
|
||||
| FR-002 | Enable integration with external data sources for historical data retrieval. | Medium | [FR-002](../requirements/FR-002.md) |
|
||||
| FR-003 | Generate comprehensive reports summarizing scenario analysis results. | High | [FR-003](../requirements/FR-003.md) |
|
||||
| FR-004 | Support user authentication and role-based access control. | High | [FR-004](../requirements/FR-004.md) |
|
||||
| FR-005 | Provide data visualization tools for better interpretation of analysis results. | Medium | [FR-005](../requirements/FR-005.md) |
|
||||
| FR-006 | Ensure system scalability to handle increasing data volumes and user load. | High | [FR-006](../requirements/FR-006.md) |
|
||||
| FR-007 | Implement audit logging for tracking user actions and system changes. | Low | [FR-007](../requirements/FR-007.md) |
|
||||
| FR-008 | Facilitate export of analysis results in various formats (PDF, Excel, etc.). | Medium | [FR-008](../requirements/FR-008.md) |
|
||||
| FR-009 | Provide a user-friendly interface accessible via web browsers. | High | [FR-009](../requirements/FR-009.md) |
|
||||
| FR-010 | Enable collaboration features for multiple users to work on scenarios simultaneously. | Medium | [FR-010](../requirements/FR-010.md) |
|
||||
|
||||
Each functional requirement is detailed in its respective document, providing a comprehensive description, rationale, acceptance criteria, and dependencies. Please refer to the linked documents for more information on each requirement.
|
||||
7
templates/README.md
Normal file
7
templates/README.md
Normal file
@@ -0,0 +1,7 @@
|
||||
# Templates for Documentation
|
||||
|
||||
This folder contains template files for various sections of the Calminer documentation. These templates serve as a starting point for creating consistent and comprehensive documentation across different topics related to the Calminer project.
|
||||
|
||||
## Available Templates
|
||||
|
||||
- [Requirements](requirements.md): A template for documenting the functional requirements of the Calminer system.
|
||||
30
templates/requirements.md
Normal file
30
templates/requirements.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Requirement Specification
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> This template provides a structured format for documenting functional requirements in the CalMiner project. It includes sections for key functional requirements and detailed specifications for each requirement.
|
||||
>
|
||||
> _Motivation:_ Clear and well-documented requirements are essential for guiding the development process and ensuring that the final product meets stakeholder needs.
|
||||
> _Form:_ Use this template to capture and organize functional requirements. Each requirement should be clearly defined, with associated details such as priority, rationale, and acceptance criteria.
|
||||
|
||||
## [Requirement ID]: [Short Description]
|
||||
|
||||
### Description
|
||||
|
||||
A detailed description of the requirement, explaining what the system must do.
|
||||
|
||||
### Priority
|
||||
|
||||
The priority level of this requirement (e.g., High, Medium, Low).
|
||||
|
||||
### Rationale
|
||||
|
||||
The justification for why this requirement is important.
|
||||
|
||||
### Acceptance Criteria
|
||||
|
||||
The conditions that must be met for the requirement to be considered complete.
|
||||
|
||||
### Dependencies
|
||||
|
||||
Any dependencies this requirement has on other requirements or system components.
|
||||
Reference in New Issue
Block a user