Internal Consistency


Internal consistency deals with artifacts on their own, independently of contexts or functions, all along the development life-cycle: requirements, analysis, design, or implementation.

Internal consistency can be checked independently of context or function (Raz Golestani)

Internal consistency can be checked independently of context or function (Raz Golestani)

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.

Reference consistency

Cross structure consistency means that the structures of persistency units are consistent with that of execution units targeting them.

Computation & update should be grouped into a single execution unit in order to match the targeted persistency unit.

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.

Semantic consistency: Roles and Partitions

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.

Consistency of symbolic representations and 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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: