GGE MS Protocol Stack (1)

XBM-WorkRoom

1. Generic GGE Protocol Stack System Architecture
Note that all the discussions below will be based on a fact that is one company’s development strategy, market position and product requirement analysis have appeared. After all, there is a game rule in capital world, which is to obtain market is to obtain world.
First of all, what characteristics should belong to a system that is capable to be delivered on time, especially a huge system, such as a GGE Protocol Stack System? The characteristics refer to correctness, reliability, extensibility, reutilization, maintenance and compatibility, etc. On the other hand, from the software engineering’s view of point, what types of system architectures should be taken account into the GGE Protocol Stack System Architecture that involves the development of new hardware and software? The GGE Protocol Stack is to adopt mixed system architectures, which are comprised of two parts, including hierarchy from bottom to top, namely 7-layer 0SI reference model, and multi-client/single-server(MC-SS), as shown by Figure 2.
<IMG src="http://www.52rd.com/Blog/uploadfile/20081923558547.jpg" border=0>
               Figure 2. Generic GGE Protocol Stack System Architecture

The GGE Protocol Stack System consists of five models, such as RTOS-based high-abstract-OS system framework (HAOSF), L1, L23, ACI/MMI and drivers.
After completing the design of system architecture, in general, it is very definitive for each model to be allocated the corresponding function and to be positioned the suitable position in whole system architecture from the macro perspective. The means that is the models are partitioned from functionality the system shows is capable of preserving the independent functionality amongst models partitioned. As a matter of fact, the functional independence amongst models is the very good principles of modularity design. We should therefore adopt what characteristics to evaluate that whether it is very excellent for the modularity design or not. At least, the following three characteristics should be employed to estimate the modularity design, superior or inferior.
Information hiding
Modular modules communicate with one another by means of only that information necessary to achieve software function, adopting the abstraction and interface.

Cohesion and Coupling
Cohesion is a measure of the relative functional strength of a module while Coupling is a measure of the relative interdependence among modules. Therefore, the relationship between cohesion and coupling is with a little flavor of “Games Theory”, that is, the high-end cohesion implies the low-end coupling with another module, on the contrary the high-end coupling indicates the low-end cohesion with it. However, modularity design should ensure the characteristic of the high-end cohesion and the low-end coupling for any module.
Closeness and Openness
Closeness figures out that whether a module can be invocated by other modules independently, but Openness points out that if a module is with the extensible property. In fact, Closeness and Openness correspond to reusability and extensibility in the software quality, respectively.