Page 147 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 6: Functional Design

still the final judge of whether a particular heuristic is useful for a particular application or not. Notes
Module size is often considered an indication of module complexity. In terms of the structure
of the system, modules that are very large may not be implementing a single function and can
therefore be broken into many modules, each implementing a different function. On the other
hand, modules that are too small may not require any additional identity and can be combined
with other modules.
However, the decision to split a module or combine different modules should not be based on
size alone. Cohesion and coupling of modules should be the primary guiding factors. A module
should be split into separate modules only if the cohesion of the original module was low, the
resulting modules have a higher degree of cohesion, and the coupling between modules does
not increase. Similarly, two or more modules should be combined only if the resulting module
has a high degree of cohesion and the coupling of the resulting module is not greater than the
coupling of the sub modules. Furthermore, a module usually should not be split or combined
with another module if it is subordinate to many different modules. As a rule of thumb, the
designer should take a hard look at modules that will be larger than about 100 lines of source
code or will be less than a couple of lines. Another parameter that can be considered while
“fine-tuning” the structure is the fan-in and fan-out of modules. Fan-in of a module is the
number of arrows coming in the module, indicating the number of super ordinates of a module.
Fan-out of a module is the number of arrows going out of that module, indicating the number
of subordinates of the module. A very high fan-out is not very desirable, as it means that the
module has to control and coordinate too many modules and may therefore be too complex.
Fan-out can be reduced by creating a subordinate and making many of the current subordinates
subordinate to the newly created module. In general the fan-out should not be increased above
five or six. Whenever possible, the fan-in should be maximized. Of course, this should not
be obtained at the cost of increasing the coupling or decreasing the cohesion of modules. For
example, implementing different functions into a single module, simply to increase the fan-in,
is not a good idea. Fan-in can often be increased by separating out common functions from
different modules and creating a module to implement that function. Another important factor
that should be considered is the correlation of the scope of effect and scope of control. The
scope of effect of a decision (in a module) is the collection of all the modules that contain any
processing that is conditional on that decision or whose invocation is dependent on the outcome
of the decision. The scope of control of a module is the module itself and all its subordinates
(not just the immediate subordinates). The system is usually simpler when the scope of effect
of a decision is a subset of the scope of control of the module in which the decision is located.
Ideally, the scope of effect should be limited to the modules that are immediate subordinates
of the module in which the decision is located. Violation of this rule of thumb often results in
more coupling between modules.

There are some methods that a designer can use to ensure that the scope of effect of a decision
is within the scope of control of the module. The decision can be removed from the module and
“moved up” in the structure. Alternatively, modules that are in the scope of effect but are not in
the scope of control can be moved down the hierarchy so that they fall within the scope of control.

A heuristic evaluation is a discount usability inspection method for computer software that helps
to identify usability problems in the user interface (UI) design. It specifically involves evaluators
examining the interface and judging its compliance with recognized usability principles (the
“heuristics”). These evaluation methods are now widely taught and practiced in the New Media
sector, where UIs are often designed in a short space of time on a budget that may restrict the
amount of money available to provide for other types of interface testing.

The heuristic to solve the problem and software engineering is not an exception. In the past also
we are seeing the use of some metric based heuristics in design and development of the software.
For example, if the number of parameters in a function is more than five gives impression that

LOVELY PROFESSIONAL UNIVERSITY 141