Three Universal methods of reducing complexity.

 

1. Partitioning

 

2. Hierarchy

 

3. Independence

 

 

Black boxes.

This leads to the development of Black Box program modules, derived from the Electronics idea.

These are characterised as follows:

 

 

Such black box systems are:

Form a device viewpoint think of HI-FI separates or low-level filters. From a programming viewpoint independent modules containing functions such as a "Generate Check digit" would be Black box.

Therefore in order to develop highly independent modules we would require modules to display individually high strength internally and that they would have weak relationships between other modules externally (weak coupling).

 

Coupling and Cohesion of modules

Module strength.

 

There are seven categories from Highest (Best to Lowest strength.

    1. Functional
    2. Informational
    3. Communicational
    4. Procedural
    5. Classical
    6. Logical
    7. Coincidental

 

 

The scale is not strict and there is some overlap

1 and 2 are particularly good and 6 and 7 are particularly bad.

The measures were developed by Glenford Myers

"based on studying modules in each category and their relative effects on module reusability, error-proneness, independence and program maintainability and extensibility."

It is not a design standard as such as sometimes lower strength modules are required for good operational reasons. In any design the aim would be to maximise the strength and realise the trade-off when this cannot be done.

 

 

Coincidental Strength

Either

    1. its function cannot be defined (the only way to describe its function is to describe its logic i.e. Step down through what the code does from section to section)
    2. OR

    3. It performs multiple completely unrelated functions.

They are obviously a bad idea but are developed because of bad partitioning of existing programs and attempts at efficiency by storing duplicate code in a module. They are not independent and tend to be closely related to calling and called modules.

Their interfaces are normally large and the chances of reuse are small.

They degrade program maintainability and extensibility and require rewriting and restructuring.

Logical Strength

 

Classical Strength

 

Procedural Strength

 

Communicational Strength

 

Sequential Strength.

 

Functional Strength

Informational Strength

 

Checking Strength of modules:

Write a sentence describing the purpose of the module and examine the sentence structure.

 

Functional Strength

Summed up with precise verb-object phrase.

Strong Imperative verb

Specific singular direct object

Compile

COBOL program

Calculate

Check digit

Encrypt

Input file

 

Informational Strength

Description of both data and functions acting on the data - terms such as CLASS, MODULE, Abstract Data Type.

This Tree Class allows trees to be created searched, read from, written to, closed.

Note each function should be functional strength and separately callable.

 

Sequential Strength.

A number of assembly line functions.

Read customer record, validate address details, enter details on order file.

 

Communicational Strength

A number of non-sequential functions working on the same data.

Calculate average and maximum overhead hours worked.

 

Procedural Strength

Names that describe the procedure or sound like a flowchart description indicate procedural strength.

Compute travel array values, and values of expenses array and write allowances table to file.

 

Classical Strength

The description has time related terms.

Start-up. End of job. Initialise. Clean-up.

 

Logical Strength

The name can be general purpose or else it indicates choice.

Validate all fields in record (enter filed number).

 

Coincidental Strength

The name does not give any information about module contents.

Miscellaneous routines. Process-Module.

 

 

Module Coupling.

Overall Coupling between modules should be:

    1. Narrow (not broad) connections.
    2. Direct (not indirect).
    3. Local (not remote)
    4. Obvious (not obscure)
    5. Flexible (not rigid)

 

Describes the inter-module relationships. It again gives descriptions of desirable and undesirable relationships.

The links vary from no connection, which is obviously between modules, which do not need to interact to a very tight content connection. Overall the aim would be to have only data coupling between related modules. But the top three are acceptable in particular circumstances.

    1. Data
    2. Stamp
    3. Control
    4. External
    5. Common
    6. Content

Data coupling is the main design goal and all communication between modules is through arguments. These arguments in the interface are simple. Again like cohesion the aim is to introduce some objectivity into design discussions.

Content Coupling

Common Coupling

Modules reference a global data structure. (Named after the COMMON statement in FORTRAN)

Myers cites 8 problems:

    1. Inhibits readability.
    2. Gives modules side effects.
    3. Introduces dependencies among "unrelated" modules.
    4. Hard to use in multiple contexts.
    5. Hard to use in other programs due to fixed global names.
    6. May involve "faking a structure" to allow access to data.
    7. Exposes modules to more data than they need.
    8. Defeats the notion of controlling data access.

 

External Coupling

Again there is global data shared but the data is simpler than in Common - only homogeneous data is required.

Homogeneous Data: Either:

 

Control Coupling

Not any one of Content, Common or External and one module explicitly controls the code of another.

For example:

 

Stamp Coupling

Data Coupling

 

Some Trade-Offs

Error Messages:

Whether to include their details where the error occurs (data coupling) or centralise them to benefit from standardisation etc. (control coupling of a limited scale) Such centralisation is often the best approach with an error number selecting a piece of text centrally.

Stamp versus Data

As the number of fields of a record used increases it becomes more sensible to send the record than a very long parameter list.

A simple rule of thumb is to base it on when the Majority of fields are needed