Chapter #5Software Design

Software design is a process of defining the architecture, components, interfaces, and other characteristics of a system or component and planning for a software solution.

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

Software design yields three levels of results:Architectural Design - The architectural design is the highest

abstract version of the system. It identifies the software as a system with many components interacting with each other. At this level, the designers get the idea of proposed solution domain.

High-level Design- The high-level design breaks the ‘single entity-multiple component’ concept of architectural design into less-abstracted view of sub-systems and modules and depicts their interaction with each other. High-level design focuses on how the system along with all of its components can be implemented in forms of modules. It recognizes modular structure of each sub-system and their relation and interaction among each other.

Detailed Design- Detailed design deals with the implementation part of what is seen as a system and its sub-systems in the previous two designs. It is more detailed towards modules and their implementations. It defines logical structure of each module and their interfaces to communicate with other modules.

Characteristics of a good software design

Correctness: A good design should correctly implement all the functionalities identified in the SRS document.

Understandability: A good design is easily understandable.

Efficiency: It should be efficient. Maintainability: It should be easily amenable to

change.

Design Principles The design process should not suffer from

"tunnel vision." A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job.

The design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model.

The design should "minimize the intellectual distance" between the software and the problem as it exists in the real world. That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain.

The design should exhibit uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components.

Design is not coding, coding is not design. Even when detailed procedural designs are created for program components, the level of abstraction of the 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. A variety of design concepts and design measures are available to assist the designer in assessing quality.

The design should be reviewed to minimize conceptual (semantic) errors.

Coupling and Cohesion

When a software program is modularized, its tasks are divided into several modules based on some characteristics.

As we know, modules are set of instructions put together in order to achieve some tasks. They are though, considered as single entity but may refer to each other to work together.

There are measures by which the quality of a design of modules and their interaction among them can be measured.

These measures are called coupling and cohesion.

Cohesion is a measure that defines the degree of intra-dependability within elements of a module. The greater the cohesion, the better is the program design.

Coupling is a measure that defines the level of inter-dependability among modules of a program. It tells at what level the modules interfere and interact with each other. The lower the coupling, the better the program.

"Coupling" describes the relationships between modules, and "cohesion" describes the relationships within them.

Structure Chart A Structure Chart (SC) in software engineering and

organizational theory, is a chart which shows the breakdown of a system to its lowest manageable levels.

They are used in structured programming to arrange program modules into a tree. Each module is represented by a box, which contains the module's name. The tree structure visualizes the relationships between modules.

SC Describe functions and sub-functions of each part of system (in more detail than a DFD)

Show relationships between common and unique modules of a computer program

Structure Chart - Module• Rectangle represents a module (program or subroutine)• Control Modules (mainline) branch to sub-modules• Library modules are reusable and can be invoked from

more than one Control Module elsewhere in the system

Data flow / Data Couple• Arrow with an empty circle • Shows the data one module passes to another

Control flow / Control Couple:• Arrow with filled circle• Shows a message (flag) which one module sends to another• Module uses a flag to signal a specific condition or action to another module

Structure Chart - Selection• A line with a diamond• Indicates that a control module determines which subordinate module will be invoked

Structure Chart - Loop • A curved arrow representing a loop One or

more modules are repeated

Structure Chart for Calculate Pay Amount Routine…..

User Interface Design

User interface is the front-end application view to which user interacts in order to use the software. User can manipulate and control the software as well as hardware by means of user interface.

Today, user interface is found at almost every place where digital technology exists, right from computers, mobile phones, cars, music players, airplanes, ships etc.

User interface is part of software and is designed such a way that it is expected to provide the user insight of the software. 

The software becomes more popular if its user interface is:AttractiveSimple to useResponsive in short timeClear to understandConsistent on all interfacing screens

UI is broadly divided into two categories:Command Line InterfaceGraphical User Interface

Command Line Interface (CLI)CLI provides a command prompt, the place where

the user types the command and feeds to the system. The user needs to remember the syntax of command and its use.

A command is a text-based reference to set of instructions, which are expected to be executed by the system. There are methods like macros, scripts that make it easy for the user to operate.

CLI uses less amount of computer resource as compared to GUI.

A text-based command line interface can have the following elements: Command Prompt, Cursor and Command

Graphical User Interface provides the user graphical means to interact with the system.

Using GUI, user interprets the software.Typically, GUI is more resource consuming than that

of CLI. With advancing technology, the programmers and designers create complex GUI designs that work with more efficiency, accuracy and speed.

A GUI system has following elements such as: Window, Menu, Icon, Tab….

Software testing

Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not.

Testing is executing a system in order to identify any gaps, errors, or missing requirements in contrary to the actual requirements.

Test Strategies for conventional Software

A strategy for software testing may also be viewed in the context of the spiral.

Unit testing begins at the vertex of the spiral and concentrates on each unit (i.e., component) of the software as implemented in source code.

Testing progresses by moving outward along the spiral, following unit testing is integration testing, where the focus is on design and the construction of the software architecture.

UNIT TESTING Unit Testing is a level of software testing where

individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed.

It aims at testing each component or unit of software to check its functionality, independently.

A unit is the smallest testable part of software. It usually has one or a few inputs and usually a single output.

In procedural programming a unit may be an individual program, function, procedure, etc.

In object-oriented programming, the smallest unit is a method, which may belong to a base/ super class, abstract class or derived/ child class.

BENEFITS of Unit TestingThe cost of fixing a defect detected during unit testing is

lesser in comparison to that of defects detected at higher levels.

Debugging is easy. Codes are more reusable. In order to make unit testing

possible, codes need to be modular. This means that codes are easier to reuse.

Unit testing increases confidence in changing/ maintaining code. If good unit tests are written and if they are run every time any code is changed, we will be able to promptly catch any defects introduced due to the change.

Problems are discovered early.Integration testing is easier.Acts as documentation of the system.

Integration Testing 

Integration Testing is a level of software testing where individual units are combined and tested as a group.

The purpose of this level of testing is to expose faults in the interaction between integrated units.

Integration Testing is performed after Unit Testing and before System Testing.

APPROACHES to Integration TestingBig Bang Top DownBottom UpHybrid

Big Bang is an approach to Integration Testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle.

So what is the difference between Big Bang Integration Testing and System Testing? Well, the former tests only the interactions between the units while the latter tests the entire system.

Top Down is an approach to Integration Testing where top level units are tested first and lower level units are tested step by step after that. This approach is taken when top down development approach is followed.

Bottom Up is an approach to Integration Testing where bottom level units are tested first and upper level units step by step after that. This approach is taken when bottom up development approach is followed.

SYSTEM TESTING System testing is the type of testing to check the

behavior of a complete and fully integrated software product based on the software requirements specification (SRS) document.

The purpose of this test is to evaluate the system’s compliance with the specified requirements.

It may include tests based on risks and/or requirement specifications, business process, use cases, or other high level descriptions of system behavior, interactions with the operating systems, and system resources.

System testing should investigate both functional and non-functional requirements of the testing.

Types of Testing

1. Black box Testing:Black-box testing is a method of software testing that

examines the functionality of an application based on the specifications. It is also known as Specifications based testing. Independent Testing Team usually performs this type of testing during the software testing life cycle.

This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see.

This method attempts to find errors in the following categories:Incorrect or missing functionsInterface errorsErrors in data structures or external database

accessBehavior or performance errorsInitialization and termination errors

BLACK BOX TESTING TECHNIQUESEquivalence partitioning: It is a software test design

technique that involves dividing input values into valid and invalid partitions and selecting representative values from each partition as test data.

Boundary Value Analysis: It is a software test design technique that involves determination of boundaries for input values and selecting values that are at the boundaries and just inside/ outside of the boundaries as test data.

Cause Effect Graphing: It is a software test design technique that involves identifying the cases (input conditions) and effects (output conditions), producing a Cause-Effect Graph, and generating test cases accordingly.

BLACK BOX TESTING ADVANTAGESTests are done from a user’s point of view and will help in

exposing discrepancies in the specifications.Tester need not know programming languages or how the

software has been implemented.Tests can be conducted by a body independent from the

developers, allowing for an objective perspective and the avoidance of developer-bias.

Test cases can be designed as soon as the specifications are complete.

DISADVANTAGESOnly a small number of possible inputs can be tested and

many program paths will be left untested.Without clear specifications, which is the situation in many

projects, test cases will be difficult to design.Tests can be redundant if the software designer/ developer

has already run a test case.

2. WHITE BOX TESTING White Box Testing (also known as Clear Box Testing,

Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is a software testing method in which the internal structure/ design/ implementation of the item being tested is known to the tester.

The tester chooses inputs to exercise paths through the code and determines the appropriate outputs.

Programming and the implementation knowledge is essential.

White Box Testing TechniquesStatement Coverage - This technique is aimed at

exercising all programming statements with minimal tests.

Branch Coverage - This technique is running a series of tests to ensure that all branches are tested at least once.

Path Coverage - This technique corresponds to testing all possible paths which means that each statement and branch is covered.