Software design concepts

Design Concepts

A set of software design concepts have evolved over a period and are important for software personnel / architects to know.
Each concept helps the software engineer to answer the following questions:
1. What criteria can be used to partition software into individual components?
2. How is function or data structure detail separated from a conceptual representation of software?
3. Are there uniform criteria that define the technical quality of a software design?

Abstraction : It allows designers to focus on solving a problem without being concerned about irrelevant lower level details. As we move through different levels of abstraction we work to create procedural abstraction which refers to a named sequence of instructions in a specific function. A data abstraction is a named collection of data that describes a data object. It means that procedural abstraction uses the information contained in the attributes of the data abstraction.

Refinement : It is a process of elaboration. It is a top-down design strategy. A macroscopic statement is decomposed and a hierarchy is developed in a stepwise fashion until programming language statements are reached.

Abstraction and refinement are complimentary concepts. Abstraction suppress low level details whereas Refinement helps the designer to reveal low level details.

Modularity : Software is divided into separately named and addressable components called modules that are integrated to satisfy problem requirements. There are five criteria that enable us to evaluate a design method with respect to its ability to define an effective modular system:

- Modular decomposability : A design method provides a systematic mechanism for decomposing the problem into sub-problems, hence, reduce the complexity and achieve the modularity.

- Modular composability : A design method enables existing design components to be assembled into a new system.

- Modular understandability : A module can be understood as a standalone unit it will be easier to build and easier to change.

- Modular continuity : Small changes to the system requirements result in changes to individual modules, rather than system-wide changes.

- Modular protection : An aberrant condition occurs within a module and its effects are constrained within the module.