VariaMos architecture

VariaMos architecture

VariaMos is an open-source Java-based tool developed using Java 1.7
Given that it’s often much easier to digest and understand a project that has been split into smaller, inter-dependent modules. Variamos’ architecture is decomposed into different modules instead of having a monolithic application. The following figure shows its high-level architecture.

Variamos modules view

Modules description

VariaMos has two main layers, the front-end with the Graphical User Interface (GUI), represented in yellow, and the back-end, represented in green, which is where all required functionalities are implemented. Inside the back-end layer there are two types of modules: supporting modules and functional modules. Each module has a very specific purpose that gathers an important high-level aspect of the supported functionality. Here we describe each module:

• Supporting modules provide basic operations used by different VariaMos' modules. To avoid circular dependencies, these modules should not depend on any functional or GUI modules.
  • Common: provides exceptions handling and utilities shared for all the modules. For easy maintenance notice that this module does not use any module for VariaMos, but it is used by the other modules.
  • I/O: provides functionalities related to VariaMos interoperability such as export XLS files, read and save JSON files, save/load models to/from XML files. We plan to extent this functionality for reading and saving variability models in different formats such as SPLOT or FAMA files.
• Functional modules implement main functionalities. If you need to extend or add new functionalities, probably you will need to add this type of modules.
  • Analysis modules:
    • HLCL: implements a high-level constraint language, by means of Java objects, used to express models in an agnostic level.
    • Solver: implements operations for reasoning with each particular constraint language according with the solver at hand. Currently, VariaMos supports SWI Prolog as solver, but we plan incorporate other solvers in the near future. This module also has rules to convert high-level constraints, expressed by using the HLCL module, into constraints expressed in SWI Prolog.
    • Reasoning: supports semantic verifications such as to identifiy if a model is void and to identify dead and false optional elements, redundancies, false product line, and (in)valid configurations. Also, this module suggests corrections to fix those defects.
  • Dynamic modelling modules:
    • Dynsup: this module provide extensibility hooks for defining new variability meta-models and also supports simulation operations, and adaptations according to external contexts and modeling using different views.

Extensions hint: If you extend or modify our current architecture be sure you avoid any cyclic dependency between modules.

Modules internal structure

Source folders

Each module follows the basic structure proposed by Maven as follows:

• src/main/java: production source code, which is compiled and assembled into a JAR file. This source code need be compiled and built
• src/main/resources: place to put images, sounds, templates, language bundles, textual, binary files used by the source code and configuration files.
• src/test/java: contains the unit test source code, which is compiled and executed using JUnit.
• src/test/resources: resources files for test. Use this in cases such as the Input (or output) data is large and complex, the input (or output) data is not easily mockable, such as a File or InputStream or when is preferably externalize the configuration files.

This structure respects the design paradigm Convention over configuration to decrease the number of decisions that a developer using the framework is required to make without necessarily losing flexibility.

Based on this structure we use Gradle for managing our task of building,testing, publishing and dependencies handling in an easy way.

Package name structure

A package is a grouping of related types providing access protection and name space management. Packages are used to make types easier to find and use, to avoid naming conflicts, and to control access [1]. Package names are written in all lower case to avoid conflict with the names of classes or interfaces.

VariaMos follows the recomended naming conventions for naming packages inside the source folder of each module. Hence, the project follows an order to organize related elements and provides a basic structure in a way that other programmers can easily join the team and know where to find each functionality.

The basic structure followd by our packages is:

revdomain.moduleName.layer.[layerImpl].feature.subfeatureN.subfeatureN+1...

Where:

• revdomain: com.variamos
• moduleName: e.g.common, HLCL, reasoning, dynsup, core
• layer:
  • model: classes that hold the data
  • core: classes that support the main business logic of the module
  • persistence: data Access Objects and database items
  • main: put the main class (if apply) that is the entry point for exploring this module
  • util: any support utility used by more than one feature inside the module, but not reusable enough to be placed in the common module.
  • services: rest or other remote API provided by the module
• feature (if apply): funtional subdivisions inside the module. e.g in the reasoning module we have defects, diagnosis, transformation
• subfeatureN, subfeatureN+1 (if apply): subdivisions inside the feauture to order the source code.

Examples

com.variamos.reasoning.core
com.variamos.reasoning.model.diagnosis
com.variamos.reasoning.model.util

Inside each source folder (src/main/java) and (src/test/java) the same package structure should be respected. E.g. The Solver module has the following internal structure:

          src/main/java
               com.variamos.solver.core
               com.variamos.solver.core.compiler
               com.variamos.solver.model
               com.variamos.solver.model.compiler
          src/test/java
               com.variamos.solver.core  //Unitary tests
               com.variamos.solver.core.compiler
          build.gradle  

References

[1] https://docs.oracle.com/javase/tutorial/java/package/packages.html