Removing redundant multiplicity constraints in UML class models

Mira Balaban, Azzam Maraee

Research output: Contribution to journalArticlepeer-review

3 Scopus citations

Abstract

Models are central for the development and management of complex systems. In order to be useful along the entire life cycle of software they must provide reliable support and enable automatic management. For that purpose, they must be precise, consistent, correct, and be subject to stringent quality verification and control criteria. Model automation calls for deep formal study of models, so that tools can provide inclusive support to users. This paper deals with optimization of multiplicity constraints in Class Models, i.e., models that provide abstraction on the static structure of software. The paper introduces an in-depth analysis of redundancy of multiplicity constraints, i.e., multiplicities that cannot be realized in any legal instance. The analysis includes: (1) a formal study of gaps of redundancies in multiplicity intervals; (2) algorithmic and rule-based methods for removing redundancies in multiplicity constraints; (3) a formal study of completeness of the algorithmic procedures, with respect to most UML class model constraints. The algorithmic procedures are implemented in our FiniteSatUSE tool. To the best of our knowledge, there is no previous study of properties of multiplicity redundancy, no completeness analysis of tightening methods, and no systematic study of these features with respect to most UML class model constraints.

Original languageEnglish
Pages (from-to)2717-2751
Number of pages35
JournalSoftware and Systems Modeling
Volume18
Issue number4
DOIs
StatePublished - 1 Aug 2019

Keywords

  • Boundary tight
  • Class models
  • Correctness
  • Formal semantics
  • MBSE
  • Model optimization
  • Multiplicity constraints
  • Multiplicity tightening
  • Quality
  • Redundancy
  • Tightening methods
  • Tightening rules
  • Verification

Fingerprint

Dive into the research topics of 'Removing redundant multiplicity constraints in UML class models'. Together they form a unique fingerprint.

Cite this