Rule Assessment

message_generator

Converts a RuleViolations object into a human-readable format.

LayerRuleViolationMessageGenerator

Bases: RuleViolationMessageGenerator

Generates a user-friendly error message for each violated rule defined on layers (as compared to modules). These messages differ slightly from messages generated for rules based on modules: 1) For absent, but expected dependencies, the verb used mirrors the verb used in the rule itself ("access" instead of "import"). 2) For unwanted dependencies, the regular syntax is used, but with an added hint on which layers the problematic modules belong to, such as "module X (layer L) imports module Y (layer M)". If a module does not belong to any layer, (no layer) will be used.

RuleViolationMessageBaseGenerator

Bases: ABC

create_rule_violation_messages(rule_violations)

Create a message about each rule violation.

Parameters:

Name	Type	Description	Default
rule_violations	RuleViolations	to convert to human-readable format	required

Returns:

Type	Description
list[str]	set of messages, each representing a rule violation

RuleViolationMessageGenerator

Bases: RuleViolationMessageBaseGenerator

Generates a user-friendly error message for each violated rule defined on modules (as compared to layers).

__init__(import_rule)

Parameters:

Name	Type	Description	Default
import_rule	bool	True if the underlying rule is an "import" instead of an "is imported" rule	required

rule_matcher

DefaultRuleMatcher

Bases: RuleMatcher

To be used for rules that operate on modules, such as "module X should not import module Y.

LayerRuleMatcher

Bases: RuleMatcher

To be used for rules that operate on layers, such as "layer X should not access layer Y. These types of rules differ from the DefaultRuleMatcher in that detected dependencies are interpreted differently. Example: Consider the rule 'modules X, Y should import module Z'. In the default case, this means that both X and Y have to import Z for the rule to apply to the evaluable. For the layer rule 'layer L containing modules X, Y should import layer M containing module Z' it is however sufficient for either X or Y to import Z.

RuleMatcher

Bases: ABC

Checks whether given modules fulfill the module and behavior requirements that have been specified for them.

match(evaluable)

Checks whether an expected behavior is exhibited by the EvaluableArchitecture. If there are any rule violations, will raise an error detailing the violations.

Parameters:

Name	Type	Description	Default
evaluable	EvaluableArchitecture	object to check	required

Raises: AssertionError

rule_violation_detector

RuleViolationBaseDetector

Bases: ABC

Base class for all classes that detect inconsistencies between the dependencies found within the evaluable architecture and the module and behavior requirements.

get_rule_violation(explicitly_requested_dependencies, not_explicitly_requested_dependencies)

Translate from the detected types of dependencies back to which behavior and dependency requirements are violated by them. Args: explicitly_requested_dependencies: dependency between the specified modules found, grouped by requested modules not_explicitly_requested_dependencies: other dependencies found beside the specified modules Returns: overview of all rule violations

RuleViolationDetector

Bases: RuleViolationBaseDetector

Based on the behavior requirement and the dependencies that have actually been (not) found in the graph, this class decides whether any of the requirements have been violated and how.

ExplicitlyRequestedDependenciesByBaseModules follow this structure: {(requested dependency, e.g. from A to B): [list of dependencies found that qualifiy as the requested dependency, e.g. A.a1 imports B, A.a2 imports B]}

NotExplicitlyRequestedDependenciesByBaseModule on the other hand are structured like this: {Module for which not explicitly requested dependencies (either from or to this module) were found: [list of such dependencies]}.

The output is a rule violation object which for each type of rule contains a list of (rule subject, rule object) modules which violate the rule. These are ordered according to the order the user used when specifying the rule, i.e. the rule subject is the original rule subject no matter if the rule is an import or be imported rule.

If multiple rule subjects have been specified, the rule needs to apply to each one of them in order not to count as being violated.

layer_rule_violation_detector

LayerRuleViolationDetector

Bases: RuleViolationBaseDetector

Detects violation of a layer rule based on the rule and detected dependencies relevant to this rule. Compared to the regular RuleViolationDetector, this detector is more lenient: For example, for a rule in the style of "layer X should import layer Y", it is sufficient if only one module from layer X imports something from layer Y. The regular detector would instead require all modules from layer X to import something from layer Y.

behavior_requirement

BehaviorRequirement

Stores information about which import behavior the checked module is supposed to exhibit.

explicitly_requested_dependency_not_allowed: bool property

Returns True if the dependency between two specific modules is not allowed.

explicitly_requested_dependency_required: bool property

Returns True if the dependency between two specific modules is required.

not_explicitly_requested_dependency_not_allowed: bool property

Returns True if no dependency between a specific module and a set of other modules is not allowed. Which other modules are not allowed is specified by the module requirement.

not_explicitly_requested_dependency_required: bool property

Returns True if a dependency between a specific module and any other modules is required. Which other modules are required is specified by the module requirement.

module_requirement

ModuleRequirement

Stores information about which module is supposed to be checked against which module.