Unit-III SOFTWARE DESIGN

(1)

1

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE UNIT-III

SOFTWARE DESIGN

SOFTWARE DESIGN: Software design - Abstraction - Modularity - Software Architecture - Effective modular design - Cohesion and Coupling - Architectural design and Procedural design - Data flow oriented design.

Software Design

The objective of Software Design phase is to take the SRS document as input and produce the output mentioned below

Different modules required to implement the solution

Control relationships among the different modules.

Interface among different modules.

Data structures of the individual modules.

Algorithms required to implementing the individual modules.

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

For assessing user requirements, an SRS (Software Requirement Specification) document is created whereas for coding and implementation, there is a need of more specific and detailed requirements in software terms. The output of this process can directly be used into implementation in programming languages.

Software design is the first step in SDLC (Software Design Life Cycle), which moves the concentration from problem domain to solution domain. It tries to specify how to fulfill the requirements mentioned in SRS.

Software design model consists of 4 designs:

• Data/class Design

• Architectural Design

• Interface Design

(2)

2

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE Translating Analysis model into a Design model:

Translating Analysis to Design process involved following steps:

(3)

3

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE Software Design Process and Design Quality

Software(s/w) design is an iterative process through which requirements are translated into a “blueprint” for constructing the s/w. As design iteration occur, subsequent refinement leads to design representation at much lower levels of abstraction.

Goal of design process

1. 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.

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

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

Design Guidelines

1. A design should exhibit an architecture that

(1) Has been created using recognizable architectural styles or patterns,

(2) Is composed of components that exhibit good design characteristics and

(3) Can be implemented in an evolutionary fashion!

2. A design should be modular; that is, the software should be logically partitioned into

elements or subsystems!

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 classes 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 connections between

components and with the external environment.

7. A design should be derived using a repeatable method that is driven by information

(4)

4

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE

8. A design should be represented using a notation that effectively communicates its meaning.

******************************************************************************

Software Design Concepts

Following are some design concepts which designer should keep in mind while preparing a design for the software.

Abstraction

Abstraction refers to a powerful design tool, which allows software designers to consider components at an abstract level, while neglecting the implementation details of the components.

IEEE defines abstraction as 'a view of a problem that extracts the essential information relevant to a particular purpose and ignores the remainder of the information.

Each step in the software process is accomplished through various levels of abstraction. At the highest level, an outline of the solution to the problem is presented whereas at the lower levels, the solution to the problem is presented in detail.

There are three commonly used abstraction mechanisms in software design, namely, functional abstraction, data abstraction and control abstraction. All these mechanisms allow us to control the complexity of the design process.

I. Procedural OR Functional abstraction:

These are the sequence of instructions that have a specific and limited function.

(5)

5

Open implies long sequence of activities (e.g. walk to the door, grasp knob, turn knob and pull the door, etc).

II. Data abstraction:

This involves specifying data that describes a data object.

Ex. Open a door. – Door is a data object.

• Data abstraction for door would encompass a set of attributes that describe the door. (E.g. door type, swing direction, opening mechanism, etc.)

III. Control abstraction:

It states the desired effect, without stating the exact mechanism of control. For example, if and while statements in programming languages (like C and C++) are abstractions of machine code implementations, which involve conditional instructions.

******************************************************************************

Modularity: –

Software is divided into separately named and addressable components which are called modules. Those are integrated to satisfy problem requirements. Modularity is a single

attribute of software that allows a program to be intellectually manageable.

Monolithic software i.e. a large program composed of a single module cannot be easily readable the number of control paths, spend of referential number of variables and overall complexity would make understanding close of impossible.

(6)

6

From above graph we can show that as the number of modules grows the effort or cost associated with integrating the module also grows.

These characteristics leads to a total cost or effort which shown in above figure. This is a M of modules that would result in minimum development cost and here another important question arises when modularity is consider how do we define an appropriate module of a given size? The answer lies in the method use to define modules within a system.

These are arteries (route) define that enable us to evaluate a design method with respect to define an effective module system.

1) Modular Decomposability: –

It provides a systematic approach for decomposing the problem into sub-problems.

If a design method provides a systematic mechanism for decomposable problem into the sub problem then we can reduce the complexity of overall problem by achieving effective modularity software.

2) Modular Compos ability: –

Modular compos ability means if a design method enable existing or reusable design components to be assembled into a new system then the modular solution does not reinventing wheel.

3) Modular Understandability: –

If a module can be understood as a standalone unit without reference to other module then it will be easier to build and easier to change.

4) Modular Continuity: –

If small changes to the system requirements results in changes to individual modules rather-then system wise changes the impact of change all other side effects should be minimized.

5) Modular Protection: –

If any unexpected condition occurs within a module and its effects are contain within that module only, the impact of other side effects should be minimized.

(7)

7

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE Software Architecture

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

Architecture focuses on how the major elements and components within an application are used by, or interact with, other major elements and components within the application.

The selection of data structures and algorithms or the implementation details of individual components are design concerns.

There is a difference between the terms architecture and design. A design is an instance of architecture similar to an object being an instance of class.

For example, consider the client-server architecture. We can design a network-centric software system in many different ways using either java platform or .net platform. So, there is, one architecture, but many designs can be created based on that architecture.

No. of different models can use to represent architecture.

• Structural Model- represent architecture as an organized collection of components

• Framework model– Increase level of design abstraction by identifying repeatable architectural design framework.

• Dynamic model– addresses behavior of the program architecture and indicating how system or structure configuration may change as a function.

• Process Model – focus on design of the business or technical process that the system must accommodate.

• Functional models – used to represent the functional hierarchy of a system.

******************************************************************************

Effective Modular Design

Effective modular design consists of three things:

• Functional Independence

• Cohesion

(8)

8

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE Functional Independence

Functional independence is achieved by developing modules with "single-minded function” and an "aversion" to excessive (unnecessary) interaction with other modules. In other words - each module addresses a specific sub-function of requirements and has a simple interface when viewed from other parts of the program structure. Independence is important –

• Easier to develop

• Easier to Test and maintain

• Error propagation is reduced

• Reusable module.

To summarize, functional independence is a key to good design, and design is the key to software quality.

Functional independence is evaluated using two criteria:

1. Cohesion

Cohesion is a measure of the relative functional strength of a module.

2. Coupling

(9)

9

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE Cohesion

Cohesion: Cohesion is the measure of strength of the association of elements within a

module. A cohesive module performs a single task within a software procedure, which has less interaction with procedures in other part of the program. In practice, designer should avoid low-level of cohesion when designing a module. Generally, low coupling results in high cohesion and vice versa.

The various types of cohesion are listed below:

• Functional cohesion:

In this, the elements within the modules contribute to the execution of one and only one problem related task.

Sequential cohesion:

(10)

10

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE Communicational cohesion:

In this, the elements within the modules perform different functions, yet each function references the same input or output information.

Procedural cohesion:

(11)

11

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE Temporal cohesion:

In this, the elements within the modules contain unrelated activities that can be carried out at the same time.

Logical cohesion:

In this, the elements within the modules perform similar activities, which are executed from outside the module.

Coincidental cohesion:

(12)

12

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE Coupling

In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are the strength of the relationships between modules.

Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Some types of coupling, in order of highest to lowest coupling, are as follows:

A module here refers to a subroutine of any kind, i.e. a set of one or more statements having a name and preferably its own set of variable names.

1. Content coupling:

Two modules are content coupled if one module changes a statement in another module, one module references or alters data contained inside another module, or one-module branches into another module. In the below figure, Modules B and Module D are content coupled.

2. Common coupling:

(13)

13

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE 3. Control coupling:

Two modules are control coupled if they communicate (passes a piece of information intended to control the internal logic) using at least one ‘control flag’. The control flag is a variable that controls decisions in subordinate or superior modules. In below figure , when Module 1 passes control flag to Module 2, Module 1 and Module 2 are said to be control coupled.

4. Stamp coupling:

Two modules are stamp coupled if they communicate through a passed data structure that contains more information than necessary for them to perform their functions. In below figure, data structure is passed between modules 1 and 4. Therefore, Module 1 and Module 4 are stamp coupled.

5. Data coupling:

Two modules are data coupled if they communicate by passing parameters. In below figure, Module 1 and Module 3 are data coupled.

6. No direct coupling:

(14)

14

******************************************************************************

Architectural Design

Requirements of the software should be transformed into an architecture that describes the software's top-level structure and identifies its components. This is accomplished through architectural design (also called system design), which acts as a preliminary 'blueprint' from which software can be developed.

IEEE defines architectural design as 'the process of defining a collection of hardware and

software components and their interfaces to establish the framework for the development of a computer system.'

This framework is established by examining the software requirements document and designing a model for providing implementation details.

These details are used to specify the components of the system along with their inputs, outputs, functions, and the interaction between them.

An architectural design performs the following functions.

1. It defines an abstraction level at which the designers can specify the functional and performance behavior of the system.

2. It evaluates all top-level designs.

3. It develops and documents top-level design for the external and internal interfaces.

(15)

15

5. It defines and documents preliminary test requirements and the schedule for software integration.

The sources of architectural design are listed below.

1. Information regarding the application domain for the software to be developed

2. Using data-flow diagrams

3. Availability of architectural patterns and architectural styles.

Architectural Design Representation

Architectural design can be represented using the following models.

1. Structural model: Illustrates architecture as an ordered collection of program

components

2. Dynamic model: Specifies the behavioral aspect of the software architecture and

indicates how the structure or system configuration changes as the function changes due to change in the external environment

3. Process model: Focuses on the design of the business or technical process, which must

be implemented in the system

4. Functional model: Represents the functional hierarchy of a system

5. Framework model: Attempts to identify repeatable architectural design patterns

encountered in similar types of application. This leads to an increase in the level of abstraction.

Architectural Design Output

The architectural design process results in an Architectural Design Document

(ADD). This document consists of a number of graphical representations that comprises software

models along with associated descriptive text. The software models include static model, interface model, relationship model, and dynamic process model. They show how the system is organized into a process at run-time.

Architectural design document gives the developers a solution to the problem stated in the Software Requirements Specification (SRS). Note that it considers only those requirements in detail that affect the program structure.

(16)

16

1. Various reports including audit report, progress report, and configuration status accounts report

2. Various plans for detailed design phase, which include the following

3. Software verification and validation plan

4. Software configuration management plan

5. Software quality assurance plan

6. Software project management plan.

******************************************************************************

Component-Level Design or Procedural design in software engineering

As soon as first iteration of architectural design is complete, component-level design also called procedural design takes place. Component-level design is created by transforming the structural elements defined by the software architecture into procedural descriptions of software components. These components are derived from the analysis model where data flow-oriented element (present in the analysis model) serves as the base for the derivation.

Component also known as module, resides within the software architecture and serves one of the three roles listed below:

• A control component, which coordinates the invocation of all other components present in the problem domain.

• A problem domain component, which implements a complete or partial function as required by the user.

• An infrastructure component supports functions, which in-turn supports the processing required in the problem domain.

(17)

17

The modular design of the software should exhibit the following sets of properties:

• Provide simple interface:

Simple interfaces reduce the number of interactions that must be considered when verifying that a system performs its intended function. Simple interfaces also make it easier to reuse components in different circumstances. Reuse is a major cost saver. Not only does it reduce the time spent in coding, design, and testing but also allows development costs to be amortized over many projects. Numerous studies have shown that reusing software design is by far the most effective technique for reducing software development costs.

• Ensure information hiding:

The benefits of modularity automatically do not follow the act of subdividing a program. Each module should encapsulate information that is not available to the rest of a program. This reduces the cost of subsequent design changes.

For example, a module may encapsulate related functions that can benefit from a common implementation or that are used in many parts of a system.

Modularity has become an accepted approach in every engineering discipline. With the introduction of modular design, complexity of software design has considerably reduced; change in the program is facilitated that has encouraged parallel development of systems.

To achieve effective modularity, design concepts like functional independence are considered to be very important.

******************************************************************************

Data flow-Oriented design

• A Data Flow Diagram (DFD) is traditional visual representation of the information flows within a system. A neat and clear DFD can represent a good amount of the system requirements graphically. It can be manual, automated, or combination of both.

• It shows how information enters and leaves the system, what changes the information and where information is stored.

(18)

18

DFD should not be confused with a flowchart. A DFD represents the flow of data

whereas flowchart depicts the flow of control. Also, a DFD does not represent the information about the procedure to be used for accomplishing the task. Hence, while making DFD, procedural details about the processes should not be shown. DFD helps a software designer to describe the transformations taking place in the path of data from input to output.

DFDs only involve four symbols. They are:

• Process

• Data Object

• Data Store

• External entity

There are several notations of the data flow diagrams. In the following, four different shapes are explained.

Process

A process is a business activity or function where the manipulation and transformation of data takes place.

Process

External Agent

(19)

19

B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE B Naresh, Lecturer in Computer Science, BVRICEB Naresh, Lecturer in Computer Science, BVRICE Data Store

• A data store represents the storage of persistent data required and/or produced by the process. Here are some examples of data stores: membership forms, database table, etc.

• Where data is being stored for later retrieval.

• Provides input to the process

• Outputs of the processes may be going into these data stores.

Data Store

Data Flow

• A data flow represents the flow of information, with its direction represented by an arrow head that shows at the end(s) of flow connector.

• Where the data is flowing.

• Represents the movement of the data in a data flow diagram.

Data Flow Model – Bank Account Management System

(20)

20

• This data flow diagram consists of the following entities.

Description:

• First we shall discuss ‘withdraw funds from an account’ process. In this process, information about the accounts and account transactions is retrieved (from the data stores) and bank releases the funds. After this, it sends this information to ‘reconcile account balance’ process which prepares a monthly account statement. In this statement, information regarding bank accounts and account transactions are described.

• Next is the ‘pay a bill’ process through which a creditor pays his dues and the corresponding accounts are updated against the cash transaction. A receipt is issued back to the creditor.