287
Systems Integration Management
Granularity and Integration
Granularity deals with the organization of EMMI as mediated by the aggregation of objects (and their mechanisms). Granularizing (or partitioning
physical entities, functions, and behaviors) into various domains is the most
important task for the designer and architect after all the requirements are
captured and characterized. Since it is exactly the iterative nature of systems
engineering that helps to surface and describe the system requirements, partitioning of objects is consequently iterative. If the granularity is too broad
(too coarse, or too wide in a hierarchical graphical representation), access to
the specific mechanism may be encumbered by other objects that must be
enacted. If the granularity is too narrow (too fine, or too narrow in a hierarchical graphical representation), access to the desired set of mechanisms
may be encumbered with multiple enactments or the desired mechanism
(and object) may be missing. While it is quite difficult to know in advance
what the optimum granularity should be, building in process managers (for
processes) and a common physical object structure (for functions) provides
flexibility without burdening either the design intent or the testing. A process manager is a module of hardware with software that is an interface
between objects. A process manager (Pikula and Siemion 2007) creates a new
process instance based on the activity model embedded in an object or a
group of cooperating objects. That activity model maps the input or output
EMMI to the object’s internal processes. Each new process instance maintains the current state of the processes for external and internal actions so
that individual processes can be executed simultaneously. After one object
completes its operation, the process manager determines which mechanism
will execute next based on the state of the process instance that is completed
and that remains to be completed. Therefore, the suite of applications used
by the process manager can be enacted independently without regard to the
sequence of steps defined in the activity model or in the overall system of
systems operations. Process integration ensures application operational
independence and allows the process manager to be domain (or object)
independent because the process manager only needs to interpret the basic
constructs that form an activity model. Testing of a process manager is the
same for all process managers, since they are designed to be identical in both
hardware and software. It is in this manner that the granularity of processes
need not be determined as precisely as needed for efficient integration.
Building flexibility through process managers overcomes the designed interfaces between objects. Again, progressive refinements to design and building objects are fundamental to the systems engineering process. In contrast,
a goal of integration is to work with a design that has included sufficient
flexibility to allow recursive integration, without iteration. Here, recursive
refers to enabling a mechanism without redesigning either the interface for
input or output, or the mechanism.
Systems Integration Management
Granularity and Integration
Granularity deals with the organization of EMMI as mediated by the aggregation of objects (and their mechanisms). Granularizing (or partitioning
physical entities, functions, and behaviors) into various domains is the most
important task for the designer and architect after all the requirements are
captured and characterized. Since it is exactly the iterative nature of systems
engineering that helps to surface and describe the system requirements, partitioning of objects is consequently iterative. If the granularity is too broad
(too coarse, or too wide in a hierarchical graphical representation), access to
the specific mechanism may be encumbered by other objects that must be
enacted. If the granularity is too narrow (too fine, or too narrow in a hierarchical graphical representation), access to the desired set of mechanisms
may be encumbered with multiple enactments or the desired mechanism
(and object) may be missing. While it is quite difficult to know in advance
what the optimum granularity should be, building in process managers (for
processes) and a common physical object structure (for functions) provides
flexibility without burdening either the design intent or the testing. A process manager is a module of hardware with software that is an interface
between objects. A process manager (Pikula and Siemion 2007) creates a new
process instance based on the activity model embedded in an object or a
group of cooperating objects. That activity model maps the input or output
EMMI to the object’s internal processes. Each new process instance maintains the current state of the processes for external and internal actions so
that individual processes can be executed simultaneously. After one object
completes its operation, the process manager determines which mechanism
will execute next based on the state of the process instance that is completed
and that remains to be completed. Therefore, the suite of applications used
by the process manager can be enacted independently without regard to the
sequence of steps defined in the activity model or in the overall system of
systems operations. Process integration ensures application operational
independence and allows the process manager to be domain (or object)
independent because the process manager only needs to interpret the basic
constructs that form an activity model. Testing of a process manager is the
same for all process managers, since they are designed to be identical in both
hardware and software. It is in this manner that the granularity of processes
need not be determined as precisely as needed for efficient integration.
Building flexibility through process managers overcomes the designed interfaces between objects. Again, progressive refinements to design and building objects are fundamental to the systems engineering process. In contrast,
a goal of integration is to work with a design that has included sufficient
flexibility to allow recursive integration, without iteration. Here, recursive
refers to enabling a mechanism without redesigning either the interface for
input or output, or the mechanism.