Software Design

 

5.1 Objectives of design 

5.2 Design framework 

5.3 Software design models 

5.4 Design process 

5.5 Architecture design 

5.6 Low level design 

5.7 Coupling and cohesion 

5.8 Software design strategies 

5.9 Function oriented design 

5.10 Object oriented design 

5.11 Function oriented design Vs Object oriented design

Software design is a process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation.

Objectives of Software Design 

     Following are the purposes of Software design:

Software Design Principles

Software design principles are concerned with providing means to handle the complexity of the design process effectively. Effectively managing the complexity will not only reduce the effort needed for design but can also reduce the scope of introducing errors during design.

Problem Partitioning 

For small problem, we can handle the entire problem at once but for the significant problem, divide the problems and conquer the problem it means to divide the problem into smaller pieces so that each piece can be captured separately. 

 For software design, the goal is to divide the problem into manageable pieces. 

 Benefits of Problem Partitioning 

 Software is easy to understand 

 Software becomes simple 

 Software is easy to test 

 Software is easy to modify

 Software is easy to maintain

 Software is easy to expand

Abstraction 

An abstraction is a tool that enables a designer to consider a component at an abstract level without bothering about the internal details of the implementation. Abstraction can be used for existing element as well as the component being designed. 

Here, there are two common abstraction mechanisms 

•  Functional Abstraction 
•  Data Abstraction 

Functional Abstraction 

• A module is specified by the method it performs. 
• The details of the algorithm to accomplish the functions are not visible to the user of the function. 
• Functional abstraction forms the basis for Function oriented design approaches. 

Data Abstraction 

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis for Object Oriented design approaches.

Modularity 

Modularity specifies to the division of software into separate modules which are differently named and addressed and are integrated later on in to obtain the completely functional software. It is the only property that allows a program to be intellectually manageable. Single large programs are difficult to understand and read due to a large number of reference variables, control paths, global variables, etc. 

There are several advantages of Modularity 

• It allows large programs to be written by several or different people 
• It encourages the creation of commonly used routines to be placed in the library and used by other programs. 
• It simplifies the overlay procedure of loading a large program into main storage. 
• It provides more checkpoints to measure progress. 
• It provides a framework for complete testing, more accessible to test 
• It produced the well designed and more readable program. 

Disadvantages of Modularity 

•  There are several disadvantages of Modularity 
•  Execution time maybe, but not certainly, longer 
•  Storage size perhaps, but is not certainly, increased 
•  Compilation and loading time may be longer 
•  Inter-module communication problems may be increased 
•  More linkage required, run-time may be longer, more source lines must be written, and more documentation has to be done 

Modular Design 

Modular design reduces the design complexity and results in easier and faster implementation by allowing parallel development of various parts of a system. We discuss a different section of modular design in detail in this section: 

1. Functional Independence: Functional independence is achieved by developing functions that perform only one kind of task and do not excessively interact with other modules. Independence is important because it makes implementation more accessible and faster. The independent modules are easier to maintain, test, and reduce error propagation and can be reused in other programs as well. Thus, functional independence is a good design feature which ensures software quality.

It is measured using two criteria: 

• Cohesion: It measures the relative function strength of a module. 
• Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules can be characterized by the design decisions that protect from the others, i.e., In other words, modules should be specified that data include within a module is inaccessible to other modules that do not need for such information.

Strategy of Design 

A good system design strategy is to organize the program modules in such a method that are easy to develop and latter too, change. Structured design methods help developers to deal with the size and complexity of programs. Analysts generate instructions for the developers about how code should be composed and how pieces of code should fit together to form a program. 

To design a system, there are two possible approaches: 

• Top-down Approach 
• Bottom-up Approach

1. Top-down Approach: This approach starts with the identification of the main components and then decomposing them into their more detailed subcomponents.

2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves towards up the hierarchy, as shown in fig. This approach is suitable in case of an existing system.

Coupling and Cohesion 

Module Coupling  

In software engineering, the coupling is the degree of interdependence between software modules. Two modules that are tightly coupled are strongly dependent on each other. However, two modules that are loosely coupled are not dependent on each other. Uncoupled modules have no interdependence at all within them.

..img

A good design is the one that has low coupling. Coupling is measured by the number of relations between the modules. That is, the coupling increases as the number of calls between modules increase or the amount of shared data is large. Thus, it can be said that a design with high coupling will have more errors.

Coupling: 

Coupling is the measure of the degree of interdependence between the modules. A good software will have low coupling.

Types of Coupling: 

• Data Coupling: If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. In data coupling, the components are independent of each other and communicate through data. Module communications don’t contain tramp data.  Example-customer billing system. 

• Stamp Coupling In stamp coupling, the complete data structure is passed from one module to another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice was made by the insightful designer, not a lazy programmer.  

 

• Control Coupling: If the modules communicate by passing control information, then they are said to be control coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring and reuse of functionality. Example- sort function that takes comparison function as an argument. 

 

• External Coupling: In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. Protocol , external file, device format, etc.

 

• Common Coupling: The modules have shared data such as global data structures. The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data accesses, and reduced maintainability. 

 

• Content Coupling: In a content coupling, one module can modify the data of another module, or control flow is passed from one module to the other module. This is the worst form of coupling and should be avoided. 

....comming Soon