Skip to main content
SpringerLink
Log in

Assessing the impact of meta-model evolution: a measure and its automotive application

  • Regular Paper
  • Published:
Software & Systems Modeling Aims and scope Submit manuscript

Abstract

Domain-specific meta-models play an important role in the design of large software systems by defining language for the architectural models. Such common modeling languages are particularly important if multiple actors are involved in the development process as they assure interoperability between modeling tools used by different actors. The main objective of this paper is to facilitate the adoption of new domain-specific meta-model versions, or a subset of the new architectural features they support, by the architectural modeling tools used by different actors in the development of large software systems. In order to achieve this objective, we developed a simple measure of meta-model evolution (named NoC—Number of Changes) that captures atomic modification between different versions of the analyzed meta-model. We evaluated the NoC measure on the evolution of the AUTOSAR meta-model, a domain-specific meta-model used in the design of automotive system architectures. The evaluation shows that the measure can be used as an indicator of effort needed to update meta-model-based tools to support different actors in modeling new architectural features. Our detailed results show the impact of 14 new AUTOSAR features on the modeling tools used by the main actors in the automotive development process. We validated our results by finding a significant correlation between the results of the NoC measure and the actual effort needed to support these features in the modeling tools reported by the modeling practitioners from four AUTOSAR tool vendors and the AUTOSAR tooling team at Volvo Cars. Generally, our study shows that quantitative analysis of domain-specific meta-model evolution using a simple measure such as NoC can be used as an indicator of the required updates in the meta-model-based tools that are needed to support new meta-model versions. However, our study also shows that qualitative analysis that may include an inspection of the actual meta-model changes is needed for more accurate assessment.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10
Fig. 11
Fig. 12
Fig. 13

Similar content being viewed by others

Notes

  1. OCA uses two dimensions for representing meta-modeling layers, where the ontological instantiation is depicted horizontally (“O” layers) and the linguistic vertically (“L” layers).

  2. Method for calculating meta-model changes related to specific features is presented in [13].

  3. Please note that this may not be true in the general case, e.g., editors of the Eclipse Graphical Modeling Framework rely on the package structure of the domain meta-model.

  4. Note that this exclusion is not part of our NoC definition as it is domain-specific, i.e., other domains may need to configure the NoC measure to exclude some other types of not relevant changes in order to increase the accuracy of the measurement results.

  5. The complete list of excluded meta-model changes and tool mappings can be found here (“ARCA_Config.xml”): https://www.chalmers.se/en/projects/Documents/ARCA.zip

  6. The complete exports from the ARCA tool can be found here (“NoC results (AR421 features)” folder): https://www.chalmers.se/en/projects/Documents/ARCA.zip

  7. We calculated the percentage of the top five features ordered both by the efforts and NoC.

  8. We consider the difference in order to be small if it is less than or equal to 3.

References

  1. Kent, S.: “Model driven engineering.” In: Proceedings of the International Conference on Integrated Formal Methods, pp. 286–299 (2002)

  2. Bézivin, J., Gerbé, O.: “Towards a precise definition of the OMG/MDA framework.” In: International Conference on Automated Software Engineering, pp. 273–280 (2001)

  3. Taylor, R., Medvidovic, N., Dashofy, E.: Software Architecture: Foundations, Theory, and Practice. Wiley, Hoboken (2009)

    Google Scholar 

  4. Saeki, M., Kaiya, H.: “On relationships among models, meta models and ontologies.” In: 6th OOPSLA Workshop on Domain-Specific Modeling, (2007)

  5. Durisic, D., Staron, M., Tichy, M., Hansson, J.: “Addressing the need for strict meta-modeling in practice—a case study of AUTOSAR.” In: International Conference on Model-Driven Engineering and Software Development, (2016)

  6. MOF 2.0 Core Specification, Object Management Group, www.omg.org (2004)

  7. Aßmann, U., Zschaler, S., Wagner, G.: “Ontologies, meta-models, and the model-driven paradigm.” In: Ontologies for Software Engineering and Software Technology. Springer Berlin Heidelberg, pp. 249–273, (2006)

  8. Atkinson, C., Kühne, T.: Model-driven development: a metamodeling foundation. J. IEEE Softw. 20(5), 36–41 (2003)

    Article  Google Scholar 

  9. Eriksson, O., Henderson-Sellers, B., Ågerfalk, P.J.: Ontological and linguistic metamodelling revisited: a language use approach. J. Inf. Softw. Technol. 55(12), 2099–2124 (2013)

    Article  Google Scholar 

  10. Pagel, M., Brörkens, M.: “Definition and generation of data exchange formats in AUTOSAR.” In: European Conference on Model Driven Architecture-Foundations and Applications, pp. 52–65 (2006)

  11. Mantz, F., Taentzer, G., Lamo, Y.: “Well-formed model co-evolution with customizable model migration.” In: Proceedings of the International Workshop on Principles of Software Evolution, pp. 1–10 (2013)

  12. Automotive Open System Architecture, AUTOSAR, www.autosar.org (2003)

  13. Durisic, D., Staron, M., Tichy, M.: “Identifying optimal sets of standardized architectural features: a method and its automotive application.” In: International ACM SIGSOFT Conference on Quality of Software Architectures, pp. 103–112 (2015)

  14. Durisic, D., Staron, M., Tichy, M., Hansson, J.: “Evolution of long-term industrial meta-models—a case study of AUTOSAR.” In: Euromicro Conference on Software Engineering and Advanced Applications, pp. 141–148 (2014)

  15. Nordstrom, G., Dawant, B., Wilkes, D.M., Karsai, G.: “Metamodeling—rapid design and evolution of domain-specific modeling environments.” In: IEEE Conference on Engineering of Computer Based Systems, pp. 68–74 (1999)

  16. Information Technology - Information Resource Dictionary System, ISO/IEC 10027 (1990)

  17. Atkinson, C., Kühne, T., Henderson-Sellers, B.: “Stereotypical encounters of the third kind.” In: In Proceedings of the 5th International Conference on The Unified Modeling Language, pp. 100–114 (2002)

  18. Gouriet, P.: “Involving AUTOSAR rules for mechatronic system design.” In: International Conference on Complex Systems Design & Management, pp. 305–316 (2010)

  19. Liu, Y., Li, Y.Q., Zhuang, R.K.: The application of automatic code generation technology in the development of the automotive electronics software. In: International Conference on Mechatronics and Industrial Informatics Conference 321–324, pp. 1574–1577 (2013)

  20. Brörkens, M., Köster, M.: “Improving the interoperability of automotive tools by raising the abstraction from legacy XML formats to standardized metamodels.” In: Proceedings of the European Conference on Model Driven Architecture-Foundations and Applications, pp. 59–67 (2007)

  21. AUTOSAR Generic Structure Template v4.2.1, www.autosar.org (2014)

  22. Yin, R.: Case Study Research: Design and Methods, 5th edn. SAGE, London (2014)

    Google Scholar 

  23. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M., Regnell, B., Wesslen, A.: Experimentation in Software Engineering. Springer, Heidelberg (2012)

    Book  MATH  Google Scholar 

  24. AUTOSAR System Template v4.2.1, www.autosar.org (2014)

  25. AUTOSAR Software Component Template v4.2.1, www.autosar.org (2014)

  26. Durisic, D., Staron, M., Tichy, M.: “ARCA - Automated analysis of AUTOSAR meta-model changes.” In: International Workshop on Modelling in Software Engineering, pp. 30–35 (2015)

  27. Meyer, M., Booker, J.: Eliciting and Analyzing Expert Judgment: A Practical Guide. Society for Industrial and Applied Mathematics, Philadelphia (2001)

  28. Fenton, N.E., Pfleeger, S.L.: Software Metrics: A Rigorous and Practical Approach, 2nd edn. International Thomson Computer Press, London (1996)

  29. Systems and Software Engineering - Measurement Process, ISO/IEC 15939 (2007)

  30. AUTOSAR Release Overview and Revision History v4.2.1, www.autosar.org (2014)

  31. Jimenez, M., Staron, D.D.M.: “Measuring the evolution of meta-models—a case study of modelica and UML meta-models,” In: International Conference on Model-Driven Engineering and Software Development (2017)

  32. Open Modelica User Guide (Releases), OpenModelica, www.openmodelica.org, (2016)

  33. Cook, T., Campbell, D.: Quasi-Experimentation: Design & Analysis Issues for Field Settings. Houghton Mifflin, Boston (1979)

    Google Scholar 

  34. Ma, Z., He, X., Liu, C.: Assessing the quality of metamodels. Front. Comput. Sci. 7(4), 558–570 (2013)

    Article  MathSciNet  Google Scholar 

  35. Rocco, J.D., Ruscio, D.D., Iovino, L., Pierantonio, A.: “Mining metrics for understanding metamodel characteristics.” In: International Workshop on Modeling in Software Engineering, pp. 55–60 (2014)

  36. Hyoseob, K., Boldyreff, C.: “Developing software metrics applicable to UML models.” In: Proceedings of the Workshop on Quantitative Approaches in Object-Oriented Software Engineering (2002)

  37. McQuillan, J.A., Power, J.F.: “On the application of software metrics to UML models.” In: Proceedings of the International Conference on Models in Software Engineering, pp. 217–226 (2007)

  38. Williams, J., Zolotas, A., Matragkas, N., Polack, F.: “What do metamodels really look like?” In: International Workshop on Experiences and Empirical Studies in Software Modeling (2013)

  39. Madhavi, K.: “A framework for visualizing model-driven software evolution.” In: Proceedings of the Conference on Advance Computing, pp. 1628–1633 (2009)

  40. Kuryazov, D., Winter, A.: “Representing model differences by delta operations.” In: International Workshop on Enterprise Distributed Object Computing, pp. 211–220 (2014)

  41. Haber, A., Hölldobler, K., Kolassa, C., Look, M., Rumpe, B., Müller, K., Schaefer, I.: “Engineering delta modeling languages.” In: International Conference on Software Product Lines, pp. 22–31 (2013)

  42. Cicchetti, A., Ruscio, D.D., Pierantonio, A.: A metamodel independent approach to difference representation. J. Obj. Technol. 6(9), 165–185 (2007)

    Article  Google Scholar 

  43. Xing, Z., Stroulia, E.: “UMLDiff: an algorithm for object-oriented design differencing.” In: International Conference on Automated Software Engineering, pp. 54–65 (2005)

  44. Kehrer, T., Rindt, M., Pietsch, P., Kelter, U.: “Generating edit operations for profiled UML models.” In: International Workshop on Models and Evolution, pp. 30–39 (2013)

  45. EMF Compare Project, http://www.eclipse.org/emf/compare, Eclipse (2015)

  46. Vermolen, S., Wachsmuth, G., Visser, E.: “Reconstructing complex metamodel evolution.” In: Proceedings of the International Conference on Software Language Engineering, pp. 201–221 (2011)

  47. Rocco, J.D., Ruscio, D.D., Iovino, L., Pierantonio, A.: “Describing the correlations between metamodels and transformations aspects.” In: Seminar on Advanced Techniques and Tools for Software Evolution, pp. 90–101 (2014)

  48. Kessentini, W.: “Automated metamodel/model co-evolution using a multi-objective optimization approach.” In: International Conference on Model Driven Engineering Languages and Systems, pp. 13–18 (2015)

Download references

Acknowledgements

The authors would like to thank Swedish Governmental Agency for Innovation Systems (VINNOVA) for funding this research (Grant No. 2013-02630) and all our industrial partners for contributing to the presented work. The authors would also like to thank Maxime Jimenez who helped us in the assessment of the presented data model for measuring the evolution of UML and Modelica meta-models.

Author information

Authors and Affiliations

  1. Volvo Car Group, Göteborg, Sweden

    Darko Durisic

  2. Chalmers University of Technology, Göteborg, Sweden

    Miroslaw Staron

  3. University of Gothenburg, Göteborg, Sweden

    Miroslaw Staron

  4. Ulm University, Ulm, Germany

    Matthias Tichy

  5. University of Skövde, Skövde, Sweden

    Jörgen Hansson

Authors
  1. Darko Durisic
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Miroslaw Staron
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Matthias Tichy
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Jörgen Hansson
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Darko Durisic.

Additional information

Communicated by Dr. Jeff Gray.

Definition of NoC using pseudo-code

Definition of NoC using pseudo-code

The calculation of the NoC for the Elements that belong to both MetaModel versions is presented in the CompareElements function in Listing 2. For each such Element, we first check whether its ClassifierName, Name, Note, Stereotype and Type have changed between the two versions and increment the NoC counter by one for each change (Listing 2, lines 2–6). We then look for changes in its Attributes, Connectors and TaggedValues considering their modifications, additions and removals (Listing 2, lines 8–43), in the way explained below.

figure f

The calculation of the NoC for the Elements present in only one MetaModel version (Elements that are either added or removed depending on the precedence of the compared meta-model versions) is presented in the MaxElementModifications function in Listing 3. For each such Element, we increment the NoC by the maximum number of possible modifications to this Element, i.e., five (one for each ClassifierName, Name, Note, Stereotype and Type, as indicated by the initial value NoC = 5 in Listing 3, line 1) plus the maximum number of possible modifications to its Attributes, Connectors and TaggedValues (Listing 3, lines 2–9), in the way explained below.

figure g

The calculation of the NoC for the Attributes that belong to both Element versions (Listing 2, lines 8–10), where the Attributes are uniquely identified by their UUID, is presented in the CompareAttributes function in Listing 4. For each such Attribute, we first check whether its LowerBound, Name, Note, Type and UpperBound have changed between the two versions and increment the NoC counter by one for each change (Listing 4, lines 3–8). We then look for changes in its TaggedValues considering their modifications, additions and removals (Listing 4, lines 10–21), in the way explained below.

figure h

The calculation of the NoC for the Attributes that are present in only one Element version (Attributes that are either added, see Listing 2, lines 16–18, or removed, see Listing 2, lines 12–14, depending on the precedence of the compared element versions) is presented in the MaxAttributeModifications function in Listing 5. For each such Attribute, we increment the NoC by the maximum number of possible modifications to this Attribute, i.e., six (one for its LowerBound, Name, Note, Stereotype, Type and UpperBound each, as indicated by the initial value NoC = 6 in Listing 5, line 1) plus one for each of its TaggedValues (Listing 5, lines 2–3).

figure i

The calculation of the NoC for the Connectors that belong to Elements is done in the same way as for the Attributes, so we skipped the description of the CompareConnectors (Listing 2, line 22) and MaxConnectorModifications (Listing 2, lines 26, 30) functions. The only difference is that in the CompareConnectors function, we increment the NoC counter by one for each change in the Note, SourceCardinality, Stereotype, TragetCardinality and Type fields between the two versions of the compared Connector, instead of LowerBound, Name, Note, Stereotype, Type and UpperBound fields (Listing 4, lines 3–8). The pseudo-code of the MaxConnectorModifications function is the same as for the MaxAttributeModifications function, but it was still defined as a standalone function for the sake of symmetry.

Finally, for each TaggedValue that belongs to both compared versions of one Element, Attribute, or Connector (Listing 2, lines 32–35 for Elements and Listing 4, lines 10–13 for Attributes), where the TaggedValues are uniquely identified by their Name, we check whether its Value has changed between the two versions and increment the NoC counter by one if it has. Additionally, for each TaggedValue that is present in only one version of the compared Element, Attribute, or Connector (TaggedValue that is either added, see Listing 2, lines 41–43 for Elements and Listing 4, lines 19–21 for Attributes, or removed, see Listing 2, lines 37–39 for Elements and Listing 4, lines 15–17 for Attributes, depending on the precedence of the compared versions of the element, attribute or connector), we increment the NoC by one.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Durisic, D., Staron, M., Tichy, M. et al. Assessing the impact of meta-model evolution: a measure and its automotive application. Softw Syst Model 18, 1419–1445 (2019). https://doi.org/10.1007/s10270-017-0601-1

Download citation

  • Received:

  • Revised:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10270-017-0601-1

Keywords

Search

Navigation