Scope
Internal consistency deals with artifacts on their own, independently of contexts or functions, all along the development life-cycle: requirements, analysis, design, or implementation.
Model Internal Consistency
Whereas internal consistency applies equally to documents, models, or code, the focus here will stay on models, which should be checked for references, structures, and semantics.
Reference consistency means that artifacts are properly referenced and used across the different documents, diagrams, or code modules. That should be dealt with by modeling tools.
Cross structure consistency means that the structures of persistency units are consistent with that of execution units targeting them.
Consistency can also be checked between actual units and their symbolic representations. For instance, while gears are physically bound to sluices they don’t have to be represented; on the other side meters must be represented but they can be moved between sluices.
Structure consistency can also be checked between the symbolic description of activities and corresponding execution units.
Semantic consistency means that the semantics of persistency units is consistent with that of execution units targeting them. At requirements levels that can be achieved by mapping roles as set by activities, and partitions as defined for objects. Since roles and partitions can be subsequently translated into abstractions, semantic consistency will be managed seamlessly at both requirements and analysis levels.
Architecture driven modelling put the onus on features impacting system architecture. From that point of view the way objects and activities are identified is highly relevant since it will define the coupling constraints between business processes and supporting systems. It follows that if couplings are to be kept at their minimum, linked activities targeting the same persistency unit should be grouped into an execution unit whenever it’s possible, the purpose being to encapsulate complexities and hiding them from architectural concerns.
More generally, representation patterns should be used to check the consistency of representations against the semantics of their actual counterparts.
The same approach can be applied to connectors.
Representation Patterns and Requirements consistency
Whereas requirements validation must deal both with what business analysts mean and what system analysts understand, by nature there isn’t much of formal specifications available at such an early stage to support an objective assessment. Nevertheless, use cases defined along representation patterns can be checked for consistency regarding inferred functional architecture.
Given that inclusion connectors introduce a hierarchy between including (higher) and included (lower) use cases it is possible to check the compatibility of stereotypes for corresponding events, actors and activities.