$3.2 FIVE RULES 47 Direct Mapping Any software system attempts to address the needs of some problem domain.If you have a good model for describing that domain,you will find it desirable to keep a clear correspondence (mapping)between the structure of the solution,as provided by the software,and the structure of the problem,as described by the model.Hence the first rule: The modular structure devised in the process of building a software system should remain compatible with any modular structure devised in the process of modeling the problem domain. This advice follows in particular from two of the modularity criteria: Continuity:keeping a trace of the problem's modular structure in the solution's structure will make it easier to assess and limit the impact of changes Decomposability:if some work has already been done to analyze the modular structure of the problem domain,it may provide a good starting point for the modular decomposition of the software. Few Interfaces The Few Interfaces rule restricts the overall number of communication channels between modules in a software architecture: Every module should communicate with as few others as possible. Communication may occur between modules in a variety of ways.Modules may call each other(if they are procedures),share data structures etc.The Few Interfaces rule limits the number of such connections. T①ypes of module interconnection structures (4) (B) (C) More precisely,if a system is composed of n modules,then the number of intermodule connections should remain much closer to the minimum,n-/,shown as (A) in the figure,than to the maximum,n (n-/)/2,shown as (B). This rule follows in particular from the criteria of continuity and protection:if there are too many relations between modules,then the effect of a change or of an error may§3.2 FIVE RULES 47 Direct Mapping Any software system attempts to address the needs of some problem domain. If you have a good model for describing that domain, you will find it desirable to keep a clear correspondence (mapping) between the structure of the solution, as provided by the software, and the structure of the problem, as described by the model. Hence the first rule: This advice follows in particular from two of the modularity criteria: • Continuity: keeping a trace of the problem’s modular structure in the solution’s structure will make it easier to assess and limit the impact of changes. • Decomposability: if some work has already been done to analyze the modular structure of the problem domain, it may provide a good starting point for the modular decomposition of the software. Few Interfaces The Few Interfaces rule restricts the overall number of communication channels between modules in a software architecture: Communication may occur between modules in a variety of ways. Modules may call each other (if they are procedures), share data structures etc. The Few Interfaces rule limits the number of such connections. More precisely, if a system is composed of n modules, then the number of intermodule connections should remain much closer to the minimum, n–1, shown as (A) in the figure, than to the maximum, n (n – 1) /2, shown as (B). This rule follows in particular from the criteria of continuity and protection: if there are too many relations between modules, then the effect of a change or of an error may The modular structure devised in the process of building a software system should remain compatible with any modular structure devised in the process of modeling the problem domain. Every module should communicate with as few others as possible. Types of module interconnection structures (A) (B) (C)