Improve Your Technology

Just another blog for techology

Software Design

Software Design Concepts and Principles

 

1. Software Design and Software Engineering

 

Software design sits at the technical kernel of software engineering and is applied regardless of the software process model that is used. Analysis provides information that is necessary to create the four design models requires for a complete specification of design. The data design transforms the information domain model created during analysis into the data structures that will be required to implement the software. The data objects and relationships defined in the entity relationship diagram and the detailed data content depicted in the data dictionary provide the basis for the data design activity.

 

The architectural design defines the relationship between major structural elements of the software, the “design patterns” that can be used to achieve the requirements that have been defined for the system, and the constrains that effect the way in which architectural design patterns can be applied.

 

The interface design describes how the software communicates within itself, with the systems that interoperate with it, and with humans who use it. The component-level design transforms structural elements of the software architecture into a procedural description of software components.

 

The importance of software design can be stated with single word – quality. Design is the place where quality is fostered in software engineering.

 

2. The Design Process

 

The design represented at a high level of abstraction; a level that can be directly traced to the specific system objective and more detailed data, functional, and behavioral requirements. As design iterations occur, subsequent refinement leads to design representations at much lower levels of abstraction.

 

2.1 Design and Software Quality

 

Three characteristics that serve of a good design:

ü        The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.

ü        The design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.

ü        The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.

 

In order to evaluate the quality of a design representation, we must establish technical criteria for good design.

(1)     A design should exhibit an architectural structure that

a.        has been created using recognizable design patterns,

b.       is composed of components that exhibit good design characteristics, and

c.        can be implemented in an evolutionary fashion, there by facilitating implementation and testing.

(2)     A design should be moderate

(3)     A design should contain distinct representations of data, architecture, interfaces, and components.

(4)     A design should lead to data structures that are appropriate for the objects to be implemented and are drawn from recognizable data patterns.

(5)     A design should lead to components that exhibit independent functional characteristics.

(6)     A design should lead to interfaces that reduce the complexity of connection between modules and with the external environment.

(7)     A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.

 

2.2 The Evolution of Software Design

 

Design work concentrated on critical for the development of modular programs and methods for refining software structures in a top-down manner. Procedural aspects of design definition evolved into a philosophy called structured programming. News design approaches proposed an object-oriented approach to design derivation.

 

Software design method introduces unique heuristics and notation, as well as a some what parochial view-of what characteristics design quality. Common characteristics:

(1)     a mechanism for the translation of analysis model into a design representation;

(2)     a notation for representing functional components and their interfaces,

(3)     heuristics for refinement and partitioning, and

(4)     guidelines for quality assessment

 

3. Design Principles

 

The design process is a sequence of steps that enables the designer to describe all aspects of the software to be built. Design process is not simply as cookbook. Basic design principles enable software engineer to navigate the design process. Following list are set of principles for software design.

 

ü        The design process should not suffer from “tunnel vision” (lack of requirements). A good design should consider alternative approaches, judging each based on the requirements of the problem.

ü        The design should be traceable to the analysis model

ü        The design should not reinvent the wheel. Design time should be invested in representing truly new ideas and integrating those patterns that already exists.

ü        The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world.

ü        The design should exhibit uniformity and integration. A design is uniform if it appears that one person develop the entire thing.

ü        The design should be structured to accommodate change.

ü        The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.

ü        Design is not coding, coding is not design. The level of abstraction of design model is higher than source code. The only design decisions made at the coding level address the small implementation details that enable the procedural design to be coded.

ü        The design should be assessed for quality as it is being created, not after the fact.

ü        The design should be reviewed to minimize conceptual errors.

 

4. Design Concepts

 

4.1 Abstraction

 

At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more procedural orientation is taken. Problem-oriented terminology is coupled with implementation-oriented terminology in an effort to state a solution. Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented.

 

Each step in the software process model is a refinement in the level of abstraction of the software solution. A procedural abstraction is named sequence of instructions that has a specific and limited function. A data abstraction is named collection of data that describes a data object. The original abstract data type is used as a template or generic data structure from which other data structure can be instantiated.

 

Control abstraction is the third form of abstraction used in software design. Like procedural and data abstraction, control abstraction implies a program control mechanism without specifying details. An example of a control abstraction is the synchronization semaphore used to coordinate activities in an operating system.

 

4.2 Refinement

 

Stepwise refinement is a top-down design strategy. A program is developed by successively refining levels of procedural detail. The process of program refinement is analogous to the process of refinement and partitioning that is used during requirements analysis.

 

Refinement is actually a process of elaboration. A high level of abstraction describes function or information conceptually but provides no information about the internal working of the function or the internal structure of the information. Abstraction and refinement are complementary concepts. Abstraction enables a designer to specify procedure and data and yet suppress low-level details. Refinement helps the designer to reveal low-level details as design progresses.

 

4.3 Modularity

 

Software is divided into separately named and addressable components, often called module, that are integrated to satisfy problem requirements. Modularity is the single attribute of software that allows a program to be intellectually manageable.

 

Five criteria that enable us to evaluate a design method with respect to its ability to define an effective modular system:

ü        Modular decomposability. If a design method provides a systematic mechanism for decomposing the problem into sub-problems. It will reduce the complexity of the overall problem, thereby achieving an effective modular solution.

ü        Modular composability. If a design method enables existing design components to be assembled into a new system, it will yield a modular solution that does not reinvent the wheel.

ü        Modular understandability. If a module can be understood as s standalone unit, it will be easier to build and easier to change.

ü        Modular continuity. If small changes to the system requirements result in changes to individual modules, rather than system wide changes, the impact of change-induced side effects will be minimized.

ü        Modular protection. If an aberrant condition occurs within a module and its effects are constrained within that module, the impact of error-induces side effects will be minimized.

 

4.4 Software Architecture

 

Software architecture alludes to “the overall structure of the software and the ways in which that structure provides conceptual integrity for a system”. Architecture is the hierarchical structure of program components, the manner in which these components interact and the structure of data that are used by the components.

 

One goal of software design is to derive an architectural rendering of a system. A set of architectural patterns enable a software engineer to reuse design level concepts.

 

Structural modules represent architecture as an organized collection of program components. Framework models increase the level of design abstraction by attempting to identify repeatable architectural design frameworks that are encountered in similar types of applications. Dynamic models address the behavioral aspects of the program architecture, indicating how the structure or system configuration may change as a function of existing events. Process models focus on the design of the business or technical process that the system must accommodate. Functional models can be used to represent the functional hierarchy of a system. Architectural description languages have been proposed, the majority provide mechanisms for describing system components and the manner in which they are connected to one another.

 

4.5 Control Hierarchy

 

Control hierarchy, also called program structure, represents the organization of program components and implies a hierarchy of control. Different notations are used to represent control hierarchy for those architectural styles that are amenable to this representation. The most common is the treelike diagram.

 

4.6 Structural Partitioning

 

Horizontal partitioning defines separate branches of the modular hierarchy for each major program function. Control modules represented in a darker shade are used to coordinate communication between and execution of the functions. Partitioning the architecture horizontal provides a number of distinct benefits:

ü        Software that is easier to test

ü        Software that is easier to maintain

ü        Propagation of fewer side effects

ü        Software that is easier to extend

 

Because major functions are decoupled from one another, change tends to be less complex and extensions to the system tend to be easier to accomplish without side effects.

 

Vertical partitioning often called factoring, suggests that control and work should be distributed top-down in the program structure. The nature of change in program structures justifies the need for vertical partitioning.

 

4.7 Data Structure

 

Data structure is a representation of the logical relationships among individual elements of data. Data structure is as important as program structure to the representation of software architecture. It dictates the organization, methods of access, degree of associatively, and processing alternatives for information.

 

A scalar item is the simplest of all data structures. A scalar item represents a single element of information that may be addressed by an identifier. When scalar items are organized as a list or contiguous group, a sequential vector is formed. When the sequential vector is extended to two, three, and ultimately, an arbitrary number of dimensions, an n-dimensional space is created. A linked list is a data structure that organizes noncontiguous scalar items, vector, or spaces in a manner that enabled them to be processed as a list. A hierarchical data structure is implemented using multilinked lists that contain scalar items, vectors, and possibly, n-dimensional spaces. A hierarchical structure is commonly encountered in applications that require information categorization and associativity.

 

4.8 Software Procedure

 

Program structure defines control hierarchy without regard to the sequence of processing and decisions. Software procedure focuses on the processing details of each module individually. Procedure must provide a precise specification of processing, including sequence of events, exact decision points, repetitive operations, and even data organization and structure.

 

4.9 Information Hiding

 

Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function. Abstraction helps to define the procedural entities that make up the software. Hiding defines and enforces access constrains to both procedural detail within a module and local data structure used by the module.

 

5. Effective Modular Design

 

5.1. Functional Independence

 

Functional independence is a direct out growth of modularity and the concept of abstraction and information hiding. Independence is measuring using two qualitative criteria: cohesion and coupling. Cohesion is measure of the relative functional strength of module. Coupling is a measure of the relative interdependence among modules.

 

5.2. Cohesion:

 

Cohesion is a natural extension of the information hiding concept. A module that performs a set of tasks that relate to each other loosely, are called as coincidentally cohesion. A module that performs tasks that are related logically is called as logically cohesion. A module that contains tasks that are related by the fact that all must be executed with the same span of time is called as temporal cohesion.

 

When processing elements of a module are related and must execute in a specific order, procedural cohesion exists. When all processing elements concentrate on one area of a data structure, communicational cohesion is present.

 

5.3. Coupling:

 

Coupling is a measure of interconnection among modules in a software structure. Coupling depends on the interface complexity between modules.

 

As long as a simple argument list is present, low coupling (data coupling) is exhibited in this portion of structure. A variation of data coupling called as stamp coupling, is found when a portion of data structure is passed via a module interface.

 

When coupling is coupling is characterized by passage of control between modules, called as control coupling. When modules are ties to an environment external to software, called as external coupling. When a number of modules reference a global data area is called as common coupling. Content coupling occurs when one module makes use of data or control information maintained within the boundary of another module. Compiler coupling ties source code to specific attributes of a compiler; operating system coupling ties design and resultant code to operating system.

 

6. Design Heuristic for Effective Modularity

 

The program structure can be manipulated according to the following set of heuristics:

1.        Evaluate the “first iteration” of the program structure to reduce coupling and improve cohesion. Once the program structure has been developed, modules may be exploded or imploded with an eye toward improving module independence. An exploded module becomes two or more modules in the final program structure. An imploded module is the result of combining the processing implied by two or more modules.

2.        Attempt to minimize structure with high fan-out; strive for fan-in as depth increases.

3.        Keep the scope of effect of a module within the scope of control of that module. The scope of effect of module is defined as all other modules that are affected by a decision made in module.

4.        Evaluate module interfaces to reduce complexity and redundancy and improve consistency. Module interface complexity is a prime cause of software errors. Interfaces should be designed to pass information simply and should be consistent with the function of a module.

5.        Define modules whose function is predictable, but avoid modules that are overly restrictive.

6.        Strive for “controlled entry” modules by avoiding “pathological connections”. This design heuristic warns against content coupling.

Advertisements

August 24, 2008 - Posted by | Design, Software Engineer |

2 Comments »

  1. Good one..!!

    Thanks…
    Mallikarjun.

    Comment by Mallikarjun | August 28, 2008 | Reply

  2. […] public links >> modularity Software Design Saved by solutionsphp on Sat 27-9-2008 Modularity in the Java Platform Saved by wizwar100 on Sun […]

    Pingback by Recent Links Tagged With "modularity" - JabberTags | September 29, 2008 | Reply


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: