SoMoX/Development/Architecture
< SoMoX | Development
Proposal for the New Architecture
Key Points for the Proposal
- Shared or required functionality from pre-migration bundles should be provided in such a way that it could be used by different approaches without these approaches having to be dependent on each other. This means that everything that is not newly added should also be used and maintained.
- Bundles shared by different analyzers, such as the SEFF extraction, should form the core of Somox. Thus, shared or required functionality should be made available to all analyzers via specified interfaces.
- The UI module is the entry point loaded by Eclipse from which the analyzers are launched.
- The UI provides a standardized Eclipse extension point that is implied by the Analyzer UI and included at runtime. Only this extension point is used to configure and call the analyzers.
- The analyzers themselves may have compile-time dependencies on the other bundles in the core of SoMoX, but the analyzers themselves should not have dependencies on each other.
- The various analysis approaches are to register with the SoMoX framework via Eclipse extension points so that they can be called via a uniform interface and return their results via a uniform interface. This is intended to make the analysis methods interchangeable to some degree. The following three analysis approaches are currently being considered for such integration:
- The Simple Model Analyzer by Klaus.
- AnnotationsMox by Manar.
- The rule-based approach by Yves.
- The various analysis approaches are to register with the SoMoX framework via Eclipse extension points so that they can be called via a uniform interface and return their results via a uniform interface. This is intended to make the analysis methods interchangeable to some degree. The following three analysis approaches are currently being considered for such integration:
- In the end, the analyzer can be implemented however anyone believes it should be implemented. As long as the following basic architectural decisions are observed:
- The input and output of all analyzers should be specified using the same interfaces.
- Analyzers are invoked through specified interfaces and communicate with shared bundles, such as the core, through interfaces only.
- No compile-time dependencies from the shared bundle to the analyzers.
- The analyzers themselves should not have compile-time dependencies on each other.
- There should be no copying of code, i.e. shared parts should be in the core of SoMoX.
- The bottom line is that SoMoX should become a framework that provides common functionality on the one hand and into which analysis procedures can also register at runtime on the other. Both should be done exclusively via interfaces, so that there are no dependencies from the SoMoX framework to the individual analysis procedures and, if possible, no dependencies between them.
Open Questions
- The goal is still to ship SoMoX in the aggregated update site of Palladio?
- The goal is still to have full compatibility with the nightly Palladio Bench?
- Will only the nightly version of the PCM be used?
- Which bundles are needed and which can be removed?
- Incompatible and current non-building bundles, like Simple Model Analyzer or Metrics, will not be migrated for now?
- Where and how should the deprecated and no longer needed bundles be archived?
- The goal is still to migrate the Simple Model Analyzer at some point?
- What should the future architecture look like?
- Where and how should the new architecture be documented?
Legacy Architecture
- org.somox.feature: The feature project for SoMoX.
- org.jgrapht: Graph Library for metric computation
- org.somox.analyzer.sissymodelanalyzer.ui:
- org.somox.analyzer.sissymodelanalyzer: Contains a model analyzer to detect and build models
- org.somox.core: Interface for ModelAnalyzer, configuration
- org.somox.filter: Contains filters to filter out objects
- org.somox.gast2seff: Creates SEFFs (Service Effect Specifications) for methods.
- org.somox.kdmhelper: Contains code to let SoMoX work with the KDM/MoDisco Java metamodel
- org.somox.metrics: Metrics for coupling computation
- org.somox.metricvaluesstorage: Persists the computed metric values per iteration
- org.somox.seff2javaast: Mapping from SEFF to java methods
- org.somox.sourcecodedecorator: Some mappings between the component model and the source code artefacts
- org.somox.ui: Tab creation
- uk.ac.shef.dcs.simmetrics: Similarity Metric Library
- org.somox.modisco.feature
- org.eclipse.gmt.modisco.java.edit: The edit project from the org.eclipse.gmt.modisco.java project
- org.eclipse.gmt.modisco.omg.kdm.edit: The edit project from the org.eclipse.gmt.modisco.omg.kdm project