A systematic identification of consistency rules for UML diagrams

Abstract

UML diagrams describe different views of one piece of software. These diagrams strongly depend on each other and must therefore be consistent with one another, since inconsistencies between diagrams may be a source of faults during software development activities that rely on these diagrams. It is therefore paramount that consistency rules be defined and that inconsistencies be detected, analyzed and fixed. The relevant literature shows that authors typically define their own UML consistency rules, sometimes defining the same rules and sometimes defining rules that are already in the UML standard. The reason might be that no consolidated set of rules that are deemed relevant by authors can be found to date. The aim of our research is to provide a consolidated set of UML consistency rules and obtain a detailed overview of the current research in this area. We therefore followed a systematic procedure in order to collect and analyze UML consistency rules. We then consolidated a set of 116 UML consistency rules (avoiding redundant definitions or definitions already in the UML standard) that can be used as an important reference for UML-based software development activities, for teaching UML-based software development, and for further research.

Multi-view Consistency in UML: A Survey

“…Many modelling tools incorporate their own rule sets [c17, c20, c52, c73]. The survey by Torre et al [41] lists 116 consistency rules studied in the literature, where 95 are syntactic (structural).…”

“…An asterisk in front of the reference indicates that more information is given in Sect. 20,28,41,42], the information of which we aligned, adapted, and extended by search queries on the Internet and personal experiences. From the 14 different UML diagram types (structural: profile, class, composite structure, component, deployment, object, package; behavioural: activity, sequence, communication, interaction overview, timing, use case, state machine [34, p. 681]), we combined, as usual, the sequence, communication, interaction overview and timing diagram into the single type of interaction diagram for conciseness; and we omitted the profile, deployment, package, and use case diagram.…”

“…A structural verification task considers a single (integrated) system state only, whereas a behavioural task pertains to a sequence of states. In contrast to [c46], here "[c]onsistency problems are structural problems and do not involve behaviour" [18, p. 122].The large number of approaches to multi-view consistency in the literature has also been reviewed and summarised [3,20,28,40,41,42]. In particular, Torre et al [40,41] systematically survey existing consistency rules.…”

“…In contrast to [c46], here "[c]onsistency problems are structural problems and do not involve behaviour" [18, p. 122].The large number of approaches to multi-view consistency in the literature has also been reviewed and summarised [3,20,28,40,41,42]. In particular, Torre et al [40,41] systematically survey existing consistency rules. They find that most rules are syntactic (88.21% in [40] and 81.89% according to the more comprehensive [41]), and that most of the rules are related to class diagrams (71.58%), sequence diagrams (47.37%), and state machine diagrams (42.11%).…”

Logical Approach: Consistency Rules between Activity Diagram and Class Diagram

“…UML is a standard modeling language to represent the requirements of the system in diagrammatic notations in object-oriented development practices. The UML currently provides 14 diagrams to visualize the requirements of the system from different aspects [2]. For example, Use Case Diagram (UCD) models the functionalities of the system, Activity diagram (AD) describes the flows of activities and actions of the system, and Class diagram (CD) describes the structure of the system [3].…”