Coupling and its types | software design

Coupling

Coupling between two modules is a measure of the degree of interdependence or interaction between the two modules. A module having high cohesion and low coupling is said to be functionally independent of other modules. If two modules interchange large amounts of data, then they are highly interdependent. The degree of coupling between two modules depends on their interface complexity.
Types of coupling

1. Data coupling
2. Stamp coupling
3. Control coupling
4. Common coupling
5. Content coupling

Data coupling: Two modules are data coupled, if they communicate through a parameter. An example is an elementary data item passed as a parameter between two modules, e.g. an integer, a float, a character, etc. This data item should be problem related and not used for the control purpose.

Stamp coupling: Two modules are stamp coupled, if they communicate using a composite data item such as a record in PASCAL or a structure in C.

Control coupling: Control coupling exists between two modules, if data from one module is used to direct the order of instructions execution in another. An example of control coupling is a flag set in one module and tested in another module.

Common coupling: Two modules are common coupled, if they share data through some global data items.

Content coupling: Content coupling exists between two modules, if they share code, e.g. a branch from one module into another module.
 

Read More [...]

Posted in Common coupling, Content coupling, Control coupling, Coupling, Data coupling, Stamp coupling, types of coupling

Cohesion and its type | software design

Cohesion
 Cohesion is a measure of functional strength of a module. A module having high cohesion and low coupling is said to be functionally independent of other modules. By the term functional independence, we mean that a cohesive module performs a single task or function. A functionally independent module has minimal interaction with other modules.

Types of cohesion:

1. coincidental cohesion
2. logical cohesion
3. Temporal cohesion
4. Procedural cohesion
5. Communicational cohesion
6.  Sequential cohesion
7.  Functional cohesion

Coincidental cohesion: A module is said to have coincidental cohesion, if it performs a set of tasks that relate to each other very loosely, if at all. In this case, the module contains a random collection of functions. It is likely that the functions have been put in the module out of pure coincidence without any thought or design. For example, in a transaction processing system (TPS), the get-input, print-error, and summarize-members functions are grouped into one module. The grouping does not have any relevance to the structure of the problem.

Logical cohesion: A module is said to be logically cohesive, if all elements of the module perform similar operations, e.g. error handling, data input, data output, etc. An example of logical cohesion is the case where a set of print functions generating different output reports are arranged into a single module.

Temporal cohesion: When a module contains functions that are related by the fact that all the functions must be executed in the same time span, the module is said to exhibit temporal cohesion. The set of functions responsible for initialization, start-up, shutdown of some process, etc. exhibit temporal cohesion.

Procedural cohesion: A module is said to possess procedural cohesion, if the set of functions of the module are all part of a procedure (algorithm) in which certain sequence of steps have to be carried out for achieving an objective, e.g. the algorithm for decoding a message.

Communicational cohesion: A module is said to have communicational cohesion, if all functions of the module refer to or update the same data structure, e.g. the set of functions defined on an array or a stack.

Sequential cohesion: A module is said to possess sequential cohesion, if the elements of a module form the parts of sequence, where the output from one element of the sequence is input to the next. For example, in a TPS, the get-input, validate-input, sort-input functions are grouped into one module.

Functional cohesion: Functional cohesion is said to exist, if different elements of a module cooperate to achieve a single function. For example, a module containing all the functions required to manage employees’ pay-roll exhibits functional cohesion. Suppose a module exhibits functional cohesion and we are asked to describe what the module does, then we would be able to describe it using a single sentence

Read More [...]

Posted in Cohesion, coincidental cohesion, Communicational cohesion, Functional cohesion, logical cohesion, Procedural cohesion, Sequential cohesion, Temporal cohesion, types of cohesion

Software design and its types

Software design deals with transforming the customer requirements, as described in the SRS document, into a form (a set of documents) that is suitable for implementation in a programming language. A good software design is seldom arrived by using a single step procedure but rather through several iterations through a series of steps.

Design activities can be broadly classified into two important parts:

Read More [...]

Posted in Detailed design, preliminary design, Software design, Software design and its types

Formal technique | Formal specification language| Formal requirements specification

Formal technique

A formal technique is a mathematical method to specify a hardware and/or software system, verify whether a specification is realizable, verify that an implementation satisfies its specification, prove properties of a system without necessarily running the system, etc. The mathematical basis of a formal method is provided by the specification language.

Read More [...]

Posted in Formal requirements specification, Formal specification language, Formal technique, satisfacation relation, semantic domains, software engineering, syntactic domains

Decision table | Requirement analysis and specification

Decision table:

A decision table is used to represent the complex processing logic in a tabular or a matrix form. The upper rows of the table specify the variables or conditions to be evaluated. The lower rows of the table specify the actions to be taken when the corresponding conditions are satisfied.

Read More [...]

Posted in Decision table, notes of software engineering, Requirement analysis and specification, software engineering

Dicision tree | Requirement analysis and specification

Decision tree :

A decision tree gives a graphic view of the processing logic involved in decision making and the corresponding actions taken. The edges of a decision tree represent conditions and the leaf nodes represent the actions to be performed depending on the outcome of testing the condition.

Example: -

Read More [...]

Posted in Dicision tree, Library Membership Automation Software, notes of software engineering, Requirement analysis and specification

properties of SRS documents | SRS documents

    The important properties of a good SRS document are the         following:
    There are six properties of good SRS document:
      1.concise
      2.structured
      3.black- box view
      4.conceptual integrity
      5.Response to undesired events
      6.verifiable
ƒ Concise: The SRS document should be concise and at the same time unambiguous, consistent, and complete. Verbose and irrelevant descriptions reduce readability and also increase error possibilities.

Read More [...]

Posted in notes of software engineering, properties of SRS documents, SRS documents