2.13.1 Module Boundary
The boundary drawn around any module or model is a convenient device to support the clear and unambiguous specification of the module and its functionality. Both physical flows and information flows take place across boundaries. Information flows include the importing and exporting of datasets. This is depicted diagrammatically in Figure 2-2.
Definition of interfaces must include definitions of all flows, that is, physical flows (discrete or continuous, or a combination of these) and information flows across the interface. This definition will be later subsumed by the model boundary when the latter is used to enable the process of joining modules. When this is done, a new boundary is created and previously existing boundaries will be replaced or re-defined. This must also be carefully defined and that definition documented. Defining each module and corresponding boundary correctly are critical activities.
Each module is translated into an equivalent, specifically defined block of code to deliver specific functionality. Modules are designed to be combined with other modules to enable construction of sectors and complete models, the latter representing complex problems with feedback structures and complex dynamic behaviour. Modules, sectors and the models into which they can be combined are time-domain or state-space representations which can represent highly non-linear feedback problems with non-zero initial values.