Stanislaw Niepostyn

• Doctor of Philosophy
• Warsaw University of Technology

In my UNCR (UNIVERSAL NOTATION FOR CONSISTENCY RULES) notation, these four consistency rules from Table III would take the form: 1. CcAi; 2. ApCc; 3. AvCch; 4. AvCch. All these rules have already been proposed by Chanda, J., Kanjilal, A., Sengupta, S., Bhattacharya, S. in the publication "Traceability of Requirements and Consistency Verification of UML UseCase, Activity and Class diagram: A Formal Approach" from 2009. The third and fourth have already been proposed by Sapna, P., G., Mohanty, H. in the publication Ensuring Consistency in Relational Repository of UML Models from 2007. The second, third and fourth were proposed by Xianhong, L. in the publication "Identification and Check of Inconsistencies between UML Diagrams" from 2013. These are so-called consistency rules very popular in the literature. And in the design of software architecture, the most used rule is BuAv, and more specifically: Bu«scenarios»An«start»(v+|i+)+n«stop». It is simply a visualization of the business use case in the form of a scenario model in the activity diagram.

What is the consistency rule?

If we consider the nature of consistency [Spanaudakis, Zisman 2001], then we imagine that the consistency rule is a relationship between

two elements of different diagrams.

Let's just consider these consistency rules, which are relations between elements of different diagrams.

If we're using the uppercase letter UML diagram type, and the lowercase UML element of this diagram, then we would get the following table for UML diagrams and the next table for UML elements.

Table 1. UML diagrams

A - Business Use Case Realization Diagram (ACT)

B - Business Use Case Diagram (UC)

C - Business Class Diagram (CLASS)

Q - Internal Use Case Realization Diagram (SD)

S - Business State Machine Diagram (STM)

U - System Use Case Diagram (UC)

Z - System Use Case Realization Diagram (ACT)

Table 2. UML elements

a - Actor (UC)

c - Class (CLASS)

h - Operation (CLASS)

i - Instance (ACT)

l - Lifeline (SD)

m - Message (SD)

p - Partition (ACT)

s - State (STM)

u - UseCase (UC)

v - Activity (ACT)

More markings for diagrams and elements can be found at

Using these designations as regular expressions, we can get some common consistency rules and, by the way, identify duplicates of the proposed consistency rules:

1. BuA - mapping between business use cases and activities [Hausmann 2002, Ibrahim 2011]

2. BaQl - mapping between business actors and sequence lifelines [Sapna 2007]

3. UaQl - mapping between system actors and sequence lifelines [Shinkawa 2006, Ibrahim 2012] - similar as 2.

4. JchQm - mapping between class operations and sequence messages [Sapna 2007, Vasilecas 2009, Khai 2011, Ibrahim 2012, Kalibatiene 2013, Xianhong 2013]

5. JcQl - mapping between classes and sequence lifelines [Sapna 2007, Khai 2011, Ibrahim 2012, Kalibatiene 2013, Xianhong 2013]

6. AvCch - mapping between activities and class operations [Sapna 2007, Chanda 2009, Xianhong 2013]

7. AiCc - mapping between activity instances and classes [Chanda 2009].

What consistency rules do you use when constructing your software architectures? I use 87 such consistency rules.

I have just published on this portal my next article, in which there is a mathematical proof that adding similar names to elements from various UML diagrams, increases the information content of software architecture (https://www.researchgate.net/publication/332963902_Proof_of_the_Decrease_in_Entropy_when_Applying_Consistency_Rules_in_Software_Architecture_of_IT_Systems?isFromSharing). Thus, the use of so-called consistency rules in UML diagrams increases the readability and ordering in software architecture. But does it cause more consistency of software architecture? And it has to be added that in most tools for creating software architecture, there is no automatic option of marking these consistency rules. Hence it is so difficult to define what are the consistency rules. But their use is extremely helpful in software development. Therefore, more or less conscious behavior in the construction of software architecture makes the most sense, because it reduces the entropy of software architecture, and thus increases its readability and organization. But at the same time, questions arise in connection with the application of consistency rules: 1) What is the consistency of software architecture, and 2) When is the architecture of the software consistent ? I believe that if the software architecture consists of consistent perspectives, it is consistent. If the perspective consists of consistency layers, it is consistent. And if the layer consists of consistency models (diagrams) it is consistent.

Behavior ? A UseCase is a specification of behavior (18.1.1) - semantic rules

Functionality ? Each UseCase specifies a unit of useful functionality (18.1.3.1)

Behavior ? A UseCase inherites from the BehavioredClassifier (Fig. 18.1) - syntactic rules

Supplemental ? Use Cases belong to Supplemental Modeling (Figure 6.1) - semantic rules

Functionality ? Port is used to provide the published functionality (11.3.3.1) - semantic rules

Structural ? A Port inherites from the Property (Fig. 11.10) - syntactic rules - &

A Property inherites from the StructuralFeature (Fig. 9.10) - syntactic rules

Structural ? Common Structure belongs to Structural Modeling (Figure 6.1) - semantic rules

Functionality ? Component that offers equivalent functionality ... (11.6.3.1) - semantic rules

Structural ? A Component inherites from the Class (Fig. 11.38) - syntactic rules

Behavior ? A Class inherites from the BehavioredClassifier (Fig. 11.15) - syntactic rules

Structural ? An EncapsulatedClassifier inherites from the StructuredClassifier (Fig. 11.10) - syntactic rules

Structural ? Common Structure belongs to Structural Modeling (Figure 6.1) - semantic rules

Functionality ? The Interfaces ... offer its full set of provided functionality (11.8.6.5) - semantic rules

Structural ? An Interface inherites from the Classifier (Fig. 10.7) - syntactic rules

Behavior ? A BehavioredClassifier is composed of InterfaceRealizations (Figure 10.7) - syntactic rules

Structural ? Common Structure belongs to Structural Modeling (Figure 6.1) - semantic rules

Software architecture is a plan for software development. Agile methods perceive software architecture as something from the past, equating it with big design up-front (BDUF)—a bad thing—leading to massive documentation and implementation of YAGNI (you ain’t gonna need it) features. Does such software architecture exist, which would be useful in agile methods?