Artifact appendix

A Unified Feature Model for Microservice Identification and Refactoring

Ana Margarida Almeida and António Rito Silva · INESC-ID, Instituto Superior Técnico, University of Lisbon

Mapping skills

The skills are non-deterministic: running one twice can produce different verdicts. That is why verify-analysis exists, and why every mapping in the evaluation is published in both its automated and its reviewed form.

The pipeline

The five mapping skills and the order they run in
The mapping pipeline. A paper yields tools and codebases; each tool is mapped from its source or its documentation; the mappings are reconciled, then merged into a union profile.

refresh-feature-model-infos is absent from the diagram because it sits outside the chain: it runs whenever the feature model changes, to keep the files that describe it in step.

Expected repository layout

The skills read and write fixed paths, so they expect the tree below. It is not this repository’s layout — the skills are archived as they were run, against an earlier working tree — so reproducing a run means rebuilding this structure around them.

.
├── feature_model/
│   └── representation/
│       ├── feature_model.xml        the canonical model the skills read
│       └── .profiles/
│           └── <tool>.profile       one colour profile per tool
├── evaluation/
│   ├── analyses/
│   │   └── <tool>/
│   │       ├── analysis.md          the mapping, every finding citing evidence
│   │       └── README.md            how the tool was obtained and run
│   └── papers/
│       └── <PaperKey>.md            the tool inventory for one paper
├── papers/
│   ├── surveys/<PaperKey>.pdf       the source papers
│   └── tools/<Tool>.pdf             the per-tool papers
└── ../extracted-codebases/
    └── <tool>/                      cloned repositories, OUTSIDE the repo

The skills