LimeSurvey architecture
From LimeSurvey Manual
This is the main public document for LimeSurvey's architecture
Overview
todo, constraints
This is the architectural documentation for the LimeSurvey application. It does not document the ecosystem surrounding it.
The architectural round trip should look like this:
Risk analysis --> quality attributes priority --> architectural decisions
This document should be reviewed, updated and discussed at least yearly.
Vision
todo
Technology stack
Programming languages:
- PHP 7.2+
- JavaScript ES6 (admin) and IE11 compatible (survey taking)
- CSS, HTML
- XML, JSON
Frameworks:
- Yii 1.1
- jQuery
- Vue 1
- PHPUnit
Tools:
- Git
- GitHub Actions
- Psalm
- CodeSniffer
- MessDetector
- Scrutinizer
- Selenium, geckodriver
Dependency management:
- Manually (should be refactored)
- Yarn
- Composer
Libraries:
- CKEditor
- kcfinder
- PDF?
- Sodium
- Twig
- PHPMailer
- pclzip
Risks
As defined in the code quality guide.
Risk identification, analysis, mitigation, monitor.
todo, probability, impact, supporting knowledge
Product risk
These risks are considering the individual LimeSurvey user or admin.
Possible mitigations are in sub-lists.
Risk | Probability | Impact | Mitigation |
---|---|---|---|
Data loss (known) | Low | Medium to high | Unit-tests and integrity tests in the CI |
Internal QA culture | |||
Possibility to enable extensive logging, from which you can reconstruct answers | |||
Data loss (unknown) | ? | ||
Unauthorized data access | Full test-suite of the permission system | ||
Blocking bugs (that could lead to data loss)' | Full test-suite of the high-priority functionality | ||
Full manual QA testing before each minor release (not for patch releases) |
Project risk
Risk | Probability | Impact | Mitigation |
---|---|---|---|
Communication | Medium | Low to medium | todo |
Regressions | High | Medium to high | Functional testing for each new feature |
Continuous effort to expand the test suit | |||
Effort to keep an eye on incoming bug reports | |||
Effort to create bug statistics and improve bug statistics |
Business risk
Internal to LimeSurvey GmbH
Quality attributes
Considering the risks above, the most important quality attributes could be considered:
- Testability
- Changeability
They can be improved by using dependency injection, and having clearer separation between the abstraction layers, including splitting the monolith into separate modules.
Function composition and the "functional core, imperative shell" pattern could also help.
Strategies to improve testability:
- Explicit dependencies
- "Functional core, imperative shell"
- Make testability explicit when designing new features
- Make testability part of refactoring efforts
Quality attributes that have good performance:
- Performance and scale
- Easy to deploy
Views
4+1 view model?
Domain
A simple domain diagram over LimeSurvey:
Layers
LimeSurvey uses a basic, monolithic MVC layered architecture.
- View layer, serving HTML, JSON or XML to the calling part (can be browser or local API machine)
- Controller layer, gluing parts together from the other layers
- Business logic layer, calculating business rules, should be fully unit-testable
- Database storage layer (also includes domain entity validation)
Refactoring should be focused on strengthening the separation between the layers.
Overview of future refactoring efforts.
Forbidden transgression between abstraction layers:
How splitting up a monolith into separate modules could look like:
Possible architecture of REST + SPA module:
Class hierarchy
todo
Controller hierarchy
ActiveRecord hierarchy
Extended core classes
Flow and state
automata between states
admin flow diagram? what makes sense to document? create survey process?
API design
todo
Security
todo