Confirming Analysis › Checking for Consistency › Resolving Inconsistencies

Resolving Inconsistencies

When CA Gen reports inconsistencies at all levels of the analysis model, it lists the current anomalies at a given point in time.

An inconsistency may have a cascade effect and generate other consequential inconsistencies in different parts of the model. It is therefore sensible to approach the resolution of inconsistencies in a structured and ordered manner, concentrating first on a model object and subsequently expanding to the neighborhood, diagram, and model.

The following sections suggest a sequence for resolving inconsistencies. Following this sequence maximizes the likelihood of resolving consequential inconsistencies and minimizes iterations of the checking and revision cycle.

Data Model Inconsistencies

• Entity Properties—These are usually at the warning level, relating to the metrics of the number of occurrences.
• Attributes—These are inconsistencies relating to attribute definition of domain, field size and the definition of permitted and default values.
• Relationships—These are warnings related to the cardinality and optionality of the relationship and about the existence of many to many and one to one relationships.
• Entity identifiers—The definition of attributes, relationships, or both, as the identifier for an entity can only be performed if the correct attributes and relationships exist.

Attributes must exist in the correct domain and not be derived.

Optional relationship must not be used as identifiers.

Failing to record attributes for an entity type generates several consistency check messages, which are presented in the following table.

The subsequent definition of attributes satisfies a number of these inconsistencies. Checking the data model again produces the messages shown in the following table.

Once an identifier for the entity type has been recorded, then the inconsistencies will have been resolved, whether that identifier includes attribute(s) and/or relationships.

Clearly, the resolution of inconsistencies in the suggested sequence does minimize the number of iterations of the checking and revision cycle, maximizing the number of consequential inconsistencies resolved.

Activity and Interaction Model Inconsistencies

• Activity hierarchy—Warnings relate to situations where non-elementary activities do not decompose into more than one lower level activity.
• Properties and usage properties—This includes activity occurrence metrics, their suggested implementation mechanism, and whether they are repetitive, elementary, or both
• Elementary processes—Expected effects, process logic and information views should be detailed for all elementary processes that are to be included in a business system.
• Expected effects—The correct definition of expected effects, throughout the hierarchy, with a manual check that the sum of the expected effects of subordinate activities is equivalent to the expected effects for their parent activities. This is necessary for confirmation of decomposition and the identification of the expected interactions elementary processes have with entities.
• Elementary process dependency—The modeling of process dependencies cannot be performed with any degree of consistency unless all the previous stages of activity modeling have been made stable. Only the correct definitions of elementary processes and expected effects allow inconsistencies at this level to be resolved.
• Information views—Once process dependency is performed, the inclusion of required information views to satisfy dependency information view requirements should form the final series of consistency checks and result in a consistent activity model.

Activity objects such as elementary processes are checked for consistency with other processes in the hierarchy, events, dependencies, and external objects.

For example, in the Activity Hierarchy Diagramming Tool, failure to properly decompose activities to elementary process level, and to completely record the expected effects those activities will have on entities, generates several consistency check messages. These may include the messages shown in the following table.

The correct decomposition of activities allows you to correctly determine expected effects for activities. If decomposition is incomplete or inconsistent, then expected effects also reveal inconsistencies.

Once decomposition is completed, the recording of consistent Expected Effects is straightforward. The following table lists messages that would typically be produced in this situation.

Expected effects inconsistencies can be resolved by matching the expected effects of parent activities with those of its subordinates. The expected effects of a parent activity must always be composed of the sum of the expected effects of all its subordinate activities.

Inconsistencies may still exist, however. These inconsistencies may not necessarily be due to inaccurate modeling or understanding of the business. You must nevertheless confirm that any inconsistencies still in existence at the end of the analysis phase are not likely to impede further work.