SoMoX/Roadmap

This page describes the current development and future perspective of SoMoX. At the current state, it's purpose is to collect requirements (conceptual as well as technical) to be discussed at the 2012th Palladio Days and to later on derive the roadmap itself.

Requirements

Conceptual

Metric Configuration

• completly switch off a subset of all metrics (at the moment some are always calculated)
  • Check / re-enable DSL for description of metrics composition
  • DSL would be nice for PB too
  • Check SMM Model / Mamba framework

Clustering vs. Model Creation

• Cluserting: which classes belong together
• Model Creation: Interface / Composition definition

Package Metrics

• intuitive package structure metric (interprete packages as components, parent package = composite component)
  • This in unclear, why does package metric we have at the moment not suffice?
  • Original design decision: directory metrics, could lead to problems with multiple source directories

Configurable Strategies

• Configurable strategies for detection.
  • Strategy Example: package = component, java interface = component interface
  • basic concept exists in somox but only one fixed strategy available at the moment
• SoMoX should support arch. constraints
  • "Constraint" to configure SoMoX's reconstruction behaviour
  • e.g. as proposed by Zdun and Haitzer, developped in MA Stritzke
  • Exact constraints are still under investigation, however, something like "All classes with named *TO should be in a component TransferObjects"

Configuration

• Find optimal configuration of metrics (automatically)

PCM Generation

• PCM model generation (transformation SAMM2PCM might not be maintained at the moment)
  • Always PCM? Our follow-up tooling uses SAMM at the moment but we could switch with reasonable effort

Decision: All participants prefer to switch to pcm

ArchiMetrix

• Deficiencies != Sissy problem patterns
• currently derived from czypersky and enterprise integration patterns book
• invite Markus to doctoral round in Karlsruhe

Technical

• Single Code Repositoy without ow2/q-impress complexity
• Reduced ramp up effort to start development
  • In principle agreed but what is needed for that? Better docu? What else?
• Each iteration has to persist the metric value graph/matrix for later analyses
• For debugging, also each iteration's graph should be persistable and viewable, e.g., with graphviz
  • SoMoX Clustering graph to review metrics (are stored with the edges)
• Somox run config: Should we still have extensible filter tabs?

Misc

• Maintain and adapt GAST2SEFF
  • We do not use SEFFs at the moment, but in the future
• Document metrics
  • Markus has some updated documentation in his PhD draft!
• Provide best practices document for use of SoMoX
  • What should it contain?
    • Metric selection
    • Weight finding
• ability for Round-trip engineering:
  • generate SAMM incremental
    • This is not round-trip, is it?
      • You are right, it is only one requirement for round-trip capability. Other requirements are the ability to 1.) add architecture information via annotation to the source code and 2.) import this annotated code (incrementally) into SoMoX. In addition we have to use a tool which generates code from a SAMM or PCM.
    • Coordinate this with MA Ch. Stritzke at UPB
    • Should that also include manual intervention from the previous roundtrip?
  • add Annotation to source code
    • This is a must requirement for UPB. Should this then use PCM and OMG GAST model??
    • Follow-up: Adapt pattern specifications for Archimetrix to any decision taken
  • importer for annotated code
    • Can you provide more details? Which code? Which annotations?
    • The importer for annotated code is needed to import source code which was annotated during a previous run of SoMoX. The annotations contain the architecture annotations mentioned above. => check relation to constraints mentioned above

Non-functional Requirements

• SoMoX has to cluster fast, e.g., ABB model in < 20s (currently about 5s)
  • FZI Gast model from QImpress
• EMF model handling should be fast, c.f. model loading issue from the past
• Missing C++ support is no issue

Decisions

• Setup somox mailing list
• Issues to Discuss with Klaus
  • Community prefers to use PCM instead of SAMM
  • Move SoMoX to palladio repository

Current Development Activities

SoMoX KDM Version

Currently, a SoMoX version based on the MoDisco extraction is developed as an alternative to the SISSy GAST model. This development is focused on the SAMM model extraction. The Beagle tool as well as the gast source decorator are not part of this activity. They must be added later on if required.