Functional Independence

The theory of functional independence is a straight outgrowth of modularity and information hiding and the concepts of abstraction. In the landmark papers on software design Wirth and Parnas allude to refinement methods which enhance module independence.  In the Later work by Myers, Stevens, and Constantine solidified the concept.

The Functional independence is achieved through developing modules with single-minded function and an aversion to excessive interaction with other modules. To Stated another way we need to design software so in which each module addresses an exact sub function of needs and has an easy interface when viewed from other component of the program structure. It is good to ask why independence is important. Software with effective modularity Example for independent modules is simple to establish because function may be interfaces and compartmentalized are simplified let's consider ramifications when development is conducted by a team. Independent modules are simple to maintain and test because secondary effects caused through design or code modification are limited error propagation is reduced and reusable modules are probably. In summarize, functional independence is a key to good design and design is the key to software excellence.

Independence is measured using 2 qualitative criteria: coupling and cohesion. The Cohesion is a measure of the relative functional strength of a module and the Coupling is a measure of the relative interdependence between modules.

The Cohesion is an accepted extension of the information hiding concept.  The cohesive module performs a single task within a software procedure needing little interaction with procedures being performed on other category of a program. The Stated simply a cohesive module should ideally do just 1 thing.

The Cohesion may be represented as a range.  We always endeavor for high cohesion while the mid- range of the spectrum is often acceptable.  The scale for cohesion is nonlinear.  Which is low-end cohesiveness is much worse than the middle range which is nearly as good as high-end cohesion. In practice a designer want not be concerned with categorizing cohesion in a specific module. When modules are designed rather the overall concept should be understood and low levels of cohesion should be avoided.

To describe somewhat facetiously the low end of the spectrum we associate the following story:

In the late year 1960s most DP managers start to recognize the worth of modularity. By Unfortunately several existing  programs  were  monolithic Example for 20,000 lines  of  undocumented Fortran  with  one  2500  line subroutine. To bring a huge computer program to the state of the art a manager asked her staff to modularize the program. This was to be done in your extra time.

One staff member asked innocently the proper length for a module under the gun. 75 lines of code came the respond. He then obtained a red pen and a ruler measured the linear distance taken through 75lines of source code and drew a red line on the source listing, then another and another. With Each red line indicated a module boundary. This method is akin to establishing software with coincidental cohesion!

A module which performs a group of tasks which relate to each other loosely if at all is termed coincidentally cohesive. The module which performs tasks in which are related logically example for a module which produces all output regardless of type is logically cohesive. When a module contains tasks which are related through the fact that all must be executed within the similar span of time the module exhibits temporal cohesion

With an example of low cohesion let's consider a module which performs error processing for an engineering analysis package. The module is called pre specified bound when computed data go above. It will performs the following tasks that are: (1) computes supplementary data based on reality computed (2)  produces  an  error  report with  graphical intention  on  the  user's  workstation; (3) performs follow-up calculations requested through the user; (4) updates a data base and (5) enables menu selection for subsequent processing. While the preceding tasks are loosely associated each is an independent  functional  entity  which  might  best  be  performed  as  a  separate  module.  By combining the functions into a single module can only serve to raise the likelihood of error propagation when a modification is made to any one of the processing tasks noted below.

Moderate stages of cohesion are comparatively close to one another in the degree of module independence. When processing parts of a module are associated and must be executed in a specific order procedural cohesion exists. When all processing parts concentrate on one area of a data structure communicational cohesion is present. High cohesion is characterized through a module which performs one distinct procedural task.

As we have previously noted that it is unnecessary to determine the precise level of cohesion. By Rather it is important to strive for high cohesion and recognizes low cohesion so which software design can be change to achieve greater functional independence.