CU-BCA-SEM-II-Software Engineering-26.10.2020

Modularity- subdivide the system-Modularity simply means to divide the system or project into smaller parts to reduce the complexity of the system or project. In the same way, modularity in design means to subdivide a system into smaller parts so that these parts can be created independently and then use these parts in different systems to perform different functions. It is necessary to divide the software into components known as modules because nowadays there are different software available like Monolithic software that is hard to grasp for software engineers. So, modularity is design has now become a trend and is also important. Architecture- design a structure of something-Architecture simply means a technique to design a structure of something. Architecture in designing software is a concept that focuses on various elements and the data of the structure. These components interact with each other and use the data of the structure in architecture. Refinement- removes impurities-Refinement simply means to refine something to remove any impurities if present and increase the quality. The refinement concept of software design is actually a process of developing or presenting the software or system in a detailed manner that means to elaborate a system or software. Refinement is very necessary to find out any error if present and then to reduce it. Pattern- a repeated form-The pattern simply means a repeated form or design in which the same shape is repeated several times to form a pattern. The pattern in the design process means the repetition of a solution to a common recurring problem within a certain context. Information Hiding- hide the information-Information hiding simply means to hide the information so that it cannot be accessed by an unwanted party. In software design, information hiding is achieved by designing the modules in a manner that the information gathered or contained in one module is hidden and it can’t be accessed by any other modules. Refactoring- reconstruct something-Refactoring simply means to reconstruct something in such a way that it does not affect the behavior or any other features. Refactoring in software design means to reconstruct the design to reduce and complexity and simplify it without affecting the behavior or its functions. Fowler has defined refactoring as “the process of 150 CU IDOL SELF LEARNING MATERIAL (SLM)

changing a software system in a way that it won’t affect the behavior of the design and improves the internal structure”. Fig 8.4 Fundamental SW design concepts The design concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are as follows: Abstraction - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose. Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a step-wise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts. Modularity - Software architecture is divided into components called modules. Modularization is a technique to divide a software system into multiple discrete and independent modules, which are expected to be capable of carrying out task(s) independently. These modules may work as basic constructs for the entire software. 151 CU IDOL SELF LEARNING MATERIAL (SLM)

Designers tend to design modules such that they can be executed and/or compiled separately and independently. Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving strategy this is because there are many other benefits attached with the modular design of a software. Advantage of modularization:  Smaller components are easier to maintain  Program can be divided based on functional aspects  Desired level of abstraction can be brought in the program  Components with high cohesion can be re-used again  Concurrent execution can be made possible  Desired from security aspect Software Architecture - It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. Good software architecture will yield a good return on investment with respect to the desired outcome of the project, e.g. in terms of performance, quality, schedule and cost. Control Hierarchy - A program structure that represents the organization of a program component and implies a hierarchy of control. Structural Partitioning - The program structure can be divided both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program function. Vertical partitioning suggests that control and work should be distributed top down in the program structure. Data Structure - It is a representation of the logical relationship among individual elements of data. In computer science, data structures are abstract structures organized in particular way that are used to organize data and provide various operations upon it. Different kinds of data structures are suited to different kinds of applications, and some are highly specialized 152 CU IDOL SELF LEARNING MATERIAL (SLM)

to specific tasks. For example, relational databases most commonly use B-tree indexes for data retrieval, while compiler implementations usually use hash tables to look up identifiers. The most common and likely well-known data structure is the array, which contains a contiguous collection of data items that can be accessed by an ordinal index. Here is the list of other most common data structures:  An associative array (also called dictionary or map) is a more flexible variation on an array, in which name-value pairs can be added and deleted freely. A hash table is a common implementation of an associative array.  A record (also called tuple or struct) is an aggregate data structure. A record is a value that contains other values, typically in fixed number and sequence and typically indexed by names. The elements of records are usually called fields or members.  A union is a data structure that specifies which of a number of permitted primitive types may be stored in its instances, e.g. float or long integer. Contrast with a record, which could be defined to contain a float and an integer; whereas in a union, there is only one value at a time. Enough space is allocated to contain the widest member datatype  A set is an abstract data structure that can store specific values, in no particular order and with no duplicate values.  A graph and a tree are linked abstract data structures composed of nodes. Each node contains a value and one or more pointers to other nodes arranged in a hierarchy. Graphs can be used to represent networks, while variants of trees can be used for sorting and searching, having their nodes arranged in some relative order based on their values.  A class is a data structure that contains data fields, like a record, as well as various methods which operate on the contents of the record. In the context of object- 153 CU IDOL SELF LEARNING MATERIAL (SLM)

oriented programming, records are known as plain old data structures to distinguish them from classes. Software Design Levels 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. Software Procedure - It focuses on the processing of each module individually. Information Hiding - Modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information. In his object model, Grady Booch mentions Abstraction, Encapsulation, Modularization, and Hierarchy as fundamental software design principles. The acronym PHAME (Principles of Hierarchy, Abstraction, Modularization, and Encapsulation) is sometimes used to refer to these four fundamental principles. 8.4 SUMMARY  The design concepts provide the software designer with a foundation from which 154 CU IDOL SELF LEARNING MATERIAL (SLM)

more sophisticated methods can be applied, System design includes activities to conceive a set of system elements that answers a specific, intended purpose, using principles and concepts; it includes assessments and decisions to select system elements that compose the system, fit the architecture of the system, and comply with traded-off system requirements. It is the complete set of detailed models, properties, and/or characteristics described into a form suitable for implementation  The architecture of a system describes its major components, their relationships (structures), and how they interact with each other. Software architecture and design includes several contributory factors such as Business strategy, quality attributes, human dynamics, design, and IT environment.  Architecture serves as a blueprint for a system. It provides an abstraction to manage the system complexity and establish a communication and coordination mechanism among components.  It defines a structured solution to meet all the technical and operational requirements, while optimizing the common quality attributes like performance and security.  Further, it involves a set of significant decisions about the organization related to software development and each of these decisions can have a considerable impact on quality, maintainability, performance, and the overall success of the final product.  Software design provides a design plan that describes the elements of a system, how they fit, and work together to fulfill the requirement of the system. The objectives of having a design plan are as follows −  To negotiate system requirements, and to set expectations with customers, marketing, and management personnel.  Act as a blueprint during the development process.  Guide the implementation tasks, including detailed design, coding, integration, and testing. 155 CU IDOL SELF LEARNING MATERIAL (SLM)

 The primary goal of the architecture is to identify requirements that affect the structure of the application. A well-laid architecture reduces the business risks associated with building a technical solution and builds a bridge between business and technical requirements. 8.5 KEY WORDS/ABBREVIATIONS  Benchmark: A standard against which measurements or comparisons can be made.  Block transfer. :(ISO) The process, initiated by a single action, of transferring one or more blocks of data.  Blueprint: An exact or detailed plan or outline. Contrast with graph.  Compatibility: (ANSI) The capability of a functional unit to meet the requirements of a specified interface.  Data: Representations of facts, concepts, or instructions in a manner suitable for communication, interpretation, or processing by humans or by automated means. 8.6 LEARNING ACTIVITY 1. Write how fundamental design concept works __________________________________________________________________________ __________________________________________________________________________ 2. What operation performed for good quality software? __________________________________________________________________________ __________________________________________________________________________ 8.7 UNIT END QUESTIONS (MCQ AND DESCRIPTIVE) A. Descriptive Types Question 1. Identify principles that are concerned with providing means to handle the complexity of 156 CU IDOL SELF LEARNING MATERIAL (SLM)

the design process? 2. With related to software design principle, elaborate the levels of phase. 3. Justify issues in architectural design in which the overall structure of the system is chosen, but the internal details of major components are ignored. 4. State technique to divide a software system into multiple discrete and independent modules which are expected to be capable of carrying out task(s) independently .explain with advantages. 5. Illustrate with an example of database, data structure made? B. Multiple Choice Questions 1. Which of these truly defines Software design? (a) Software design is an activity subjected to constraints (b) Software Design specifies nature and composition of software product (c) Software Design satisfies client needs and desires (d) All of the mentioned 2. Which of the following statement is false? (a) A process is a collection of related tasks that transforms a set of inputs to the set of output (b) A design notation is a symbolic representational system (c) A design heuristic is a rule proceeding guidance, with guarantee for achieving some end (d) Software design method is orderly procedure for providing software design solutions 3. Which of these describes stepwise refinement? (a) Nicklaus Wirth described the first software engineering method as stepwise refinement (b) Stepwise refinement follows its existence from 1971 (c) It is a top down approach (d) All of the mentioned 4. What is incorrect about structural design? 157 CU IDOL SELF LEARNING MATERIAL (SLM)

(a) Structural design introduced notations and heuristics (b) Structural design emphasis on procedural decomposition (c) The advantage is data flow representation (d) It follows Structure chart 5. What is the solution for Structural design? (a) The specification model following data flow diagram (b) Procedures represented as bubbles (c) Specification model is structure chart showing procedure calling hierarchy and flow of data in and out of procedures (d) Emphasizing procedural decomposition Answers 1. (d), 2. (b), 3. (d), 4. (c), 5. (c) 8.8 REFERENCES  Pressman R.S. (2009). Software Engineering - A Practitioner’s Approach. New Delhi: MGH Publications.  Mall R. (2003). Fundamentals of Software Engineering. New Delhi: PHI  Jalote P. (2019). An Integrated Approach to Software Engineering. New Delhi: Narosa Publications.  Summerville I. (2013). Software Engineering. New Delhi: Pearson Education.  Software Engineering, Sixth Edition, 20~1, Ian Sommerville; Pearson Education.  “Fundamentals of Software Engineering” by Rajib Mall  “Software Engineering” by Gaurav Gupta and Deepika Gupta  Software Engineering 1st Edition” by Udit Agarwal  http://softwareengineeringhub.blogspot.in/2010/03/system- requirementsspecification.html  http://computersciencesource.wordpress.com/2010/03/14/softwareengineering- 158 CU IDOL SELF LEARNING MATERIAL (SLM)

object-oriented-modelling/  http://www.software-requirements.tuffley.com/sample.pdf  Machine Learning Applications In Software Engineering (Series on Software Engineering and Knowledge Engineering)” by Du Zhang and Jeffrey J P Tsai  A Privacy Awareness System for Software Design Omoronyia I.Etuk U. Inglis P.  Comparison of software design models: An extended systematic mapping studies Gonçales L. J. Farias K.  A survey of experienced user perceptions about software design patterns Zhang C. Budgen D. 159 CU IDOL SELF LEARNING MATERIAL (SLM)

UNIT 9 SOFTWARE DESIGN 2 160 Structure 9.0. Learning objectives 9.1. Introduction 9.2. Data design 9.3. Architectural design 9.3.1 Taxonomy of Architectural styles: 9.3.2 Data flow architectures: 9.4. Procedural design 9.4.1 Layered architecture: 9.4.2 Object -oriented concepts 9.4.3 Design Process 9.5. Object -oriented concepts 9.6. Summary 9.7. Key words/abbreviations 9.8. Learning activity 9.9. Unit end questions (MCQ and Descriptive) 9.10. References 9.0 LEARNING OBJECTIVES After studying this unit, you will be able to: CU IDOL SELF LEARNING MATERIAL (SLM)

 Discuss the principles of design  Discuss the basics of data design  Explain Architectural design  Illustrate Procedural design  Demonstrate Object -oriented concepts 9.1 INTRODUCTION The systems objectives outlined during the feasibility study serve as the basis from which the work of system design is initiated. Much of the activities involved at this stage are of technical nature requiring a certain degree of experience in designing systems, sound knowledge of computer related technology and through understanding of computers available in the market and the various facilities provided by the vendors. Nevertheless, a system cannot be designed in isolation without the active involvement of the user. The user has a vital role to play at this stage too. As we know that data collected during feasibility study will be utilized systematically during the system design. It should, however, be kept in mind that detailed study of the existing system is not necessarily over with the completion of the feasibility study. Depending on the plan of feasibility study, the level of detailed study will vary and the system design stage will also vary in the amount of investigation that still needs to be done. Sometimes, but rarely, the investigation may form a separate stage between feasibility study and computer system design. Designing a new system is a creative process which calls for logical as well as lateral thinking. The logical approach involves systematic moves towards the end-product keeping in mind the capabilities of the personnel and the equipment. This is to ensure that no efforts are being made to fit previous solutions into new situations Systems design is the process of defining elements of a system like modules, architecture, components and their interfaces and data for a system based on the specified requirements. It is the process of defining, developing and designing systems which satisfies the specific needs and requirements of a business or organization. A systemic approach is required for a coherent and well-running system. Bottom-Up or Top-Down approach is required to take into account all related variables of the system. A designer uses the modelling languages to express the information and knowledge in a structure of system 161 CU IDOL SELF LEARNING MATERIAL (SLM)

that is defined by a consistent set of rules and definitions. The designs can be defined in graphical or textual modelling languages. Design transforms the information model created during analysis stage into data structures in order to implement the software. E-R diagrams and the data dictionaries are used as the basis for the design activities. The architectural design defines the relationship between structural elements of the software, the design patterns and the constraints. The interface design model describes how the software communicates with itself, with the system and with the humans who use it. Thus an interface depicts a flow of information and behavior. The component-level design converts the structural elements of the software architecture into a procedural description of software components. This information can be obtained in the form of PSPEC, CSPEC and STD. Thus, a design affects the effectiveness of the software that is being built. It fosters the quality of the software engineering Features of a Good Design  It must implement all the explicit requirements contained in the analysis stage and all the implicit requirements mentioned by the customer.  It must be readable and understandable for those who code, test and support.  It must address the data, functional and behavioral aspects for the implementation of the software.  It must exhibit an architectural structure.  It must be modular i.e. the software must be partitioned into separate logical units to perform specific functions.  It must contain distinct representation of data, architecture, interface and modules Design is both a process and a model. Good design is a result of creative skills, past experience and a commitment to quality. Basic design principles allow a software engineer to ship through the design process. The principles listed below are suggested by Davis: 1. The design process must not suffer from “tunnel” vision. It must consider alternative 162 CU IDOL SELF LEARNING MATERIAL (SLM)

approaches based on alternative requirements, resources available and the design concepts. 2. The design should be traceable to the analysis model. Because the design includes a lot of requirements, there must be a clear indication of the tracking of all these requirements in the design document. 3. The design must not reinvent the wheel. Because of time and resource constraint design must always try to implement new ideas using the already existing design patterns. 4. The design should minimize the distance between the software and the problem, i.e. design must mimic the structure of the problem domain. 5. The design must exhibit uniformity and integration. While creating the design standard styles and formats should be followed by the design team. The design components should be carefully integrated and the interfaces should be clearly defined. 6. The design should be structured to accommodate change. 7. The design should be structured to degrade eventually in the event of abnormal data, events and circumstances. 8. Design must be separated from coding in terms of data abstraction. Thus, the level of data hiding is higher in design than in coding. While coding every minute detail must be taken care of. 9. The design must be assessed for quality during creation. 10. The design must be reviews to minimize the semantic error 9.2 DATA DESIGN Data design is the first design activity, which results in fewer complexes, modular and efficient program structure. The information domain model developed during analysis phase is transformed into data structures needed for implementing the software. The data objects, attributes, and relationships depicted in entity relationship diagrams and the information stored in data dictionary provide a base for data design activity. During the 163 CU IDOL SELF LEARNING MATERIAL (SLM)

data design process, data types are specified along with the integrity rules required for the data. For specifying and designing efficient data structures, some principles should be followed. These principles are listed below. The data structures needed for implementing the software as well-as the operations that can be applied on them should be identified.  A data dictionary should be developed to depict how different data objects interact with each other and what constraints are to be imposed on the elements of data structure.  Stepwise refinement should be used in data design process and detailed design decisions should be made later in the process.  Only those modules that need to access data stored in a data structure directly should be aware of the representation of the data structure.  A library containing the set of useful data structures along with the operations that can be performed on them should be maintained.  Language used for developing the system should support abstract data types. The structure of data can be viewed at three levels, namely, program component level, application level, and business level. At the program component level, the design of data structures and the algorithms required to manipulate them is necessary, if high-quality software is desired. At the application level, it is crucial to convert the data model into a database so that the specific business objectives of a system could be achieved. At the business level, the collection of information stored in different databases should be reorganized into data warehouse, which enables data mining that has an influential impact on the business. 9.3 ARCHITECTURAL DESIGN The software needs the architectural design to represents the design of software. 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.” The software that is built for computer-based systems can exhibit one of 164 CU IDOL SELF LEARNING MATERIAL (SLM)

these many architectural styles. Each style will describe a system category that consists of:  A set of components (e.g.: a database, computational modules) that will perform a function required by the system.  The set of connectors will help in coordination, communication, and cooperation between the components.  Conditions that how components can be integrated to form the system.  Semantic models that help the designer to understand the overall properties of the system.  The use of architectural styles is to establish a structure for all the components of the system. 9.3.1 Taxonomy of Architectural styles: Data centered architectures: A data store will reside at the center of this architecture and is accessed frequently by the other components that update, add, delete or modify the data present within the store. The figure illustrates a typical data centered style. The client software access a central repository. Variation of this approach is used to transform the repository into a blackboard when data related to client or data of interest for the client change the notifications to client software. This data-centered architecture will promote integrability. This means that the existing components can be changed and new client components can be added to the architecture without the permission or concern of other clients. Data can be passed among clients using blackboard mechanism. 165 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 9.1 Data centered architecture 9.3.2 Data flow architectures:  This kind of architecture is used when input data to be transformed into output data through a series of computational manipulative components.  The figure represents pipe-and-filter architecture since it uses both pipe and filter and it has a set of components called filters connected by pipes.  Pipes are used to transmit data from one component to the next.  Each filter will work independently and is designed to take data input of a certain form and produces data output to the next filter of a specified form. The filters don’t require any knowledge of the working of neighboring filters.  If the data flow degenerates into a single line of transforms, then it is termed as batch sequential. This structure accepts the batch of data and then applies a series of sequential components to transform it. 166 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 9.2 Data flow architecture Call and Return architectures: It is used to create a program that is easy to scale and modify. Many sub-styles exist within this category. Two of them are explained below. Remote procedure call architecture: This component is used to present in a main program or sub program architecture distributed among multiple computers on a network. Main program or Subprogram architectures: The main program structure decomposes into number of subprograms or function into a control hierarchy. Main program contains number of subprograms that can invoke other components. Fig 9.3 Main program architecture 167 CU IDOL SELF LEARNING MATERIAL (SLM)

9.3 PROCEDURAL DESIGN Component-based architecture focuses on the decomposition of the design into individual functional or logical components that represent well-defined communication interfaces containing methods, events, and properties. It provides a higher level of abstraction and divides the problem into sub-problems, each associated with component partitions. The primary objective of component-based architecture is to ensure component reusability. A component encapsulates functionality and behaviors of a software element into a reusable and self-deployable binary unit. There are many standard component frameworks such as COM/DCOM, JavaBean, EJB, CORBA, .NET, web services, and grid services. These technologies are widely used in local desktop GUI application design such as graphic JavaBean components, MS ActiveX components, and COM components which can be reused by simply drag and drop operation. Component-oriented software design has many advantages over the traditional object- oriented approaches such as −  Reduced time in market and the development cost by reusing existing components.  Increased reliability with the reuse of the existing components. What is a Component?  A component is a modular, portable, replaceable, and reusable set of well-defined functionality that encapsulates its implementation and exporting it as a higher-level interface.  A component is a software object, intended to interact with other components, encapsulating certain functionality or a set of functionalities. It has an obviously defined interface and conforms to a recommended behavior common to all components within an architecture.  A software component can be defined as a unit of composition with a contractually specified interface and explicit context dependencies only. That is, a software 168 CU IDOL SELF LEARNING MATERIAL (SLM)

component can be deployed independently and is subject to composition by third parties. Views of a Component-A component can have three different views − object-oriented view, conventional view, and process-related view.  Object-oriented view-A component is viewed as a set of one or more cooperating classes. Each problem domain class (analysis) and infrastructure class (design) are explained to identify all attributes and operations that apply to its implementation. It also involves defining the interfaces that enable classes to communicate and cooperate.  Conventional view-It is viewed as a functional element or a module of a program that integrates the processing logic, the internal data structures that are required to implement the processing logic and an interface that enables the component to be invoked and data to be passed to it.  Process-related view-In this view, instead of creating each component from scratch, the system is building from existing components maintained in a library. As the software architecture is formulated, components are selected from the library and used to populate the architecture.  A user interface (UI) component includes grids, buttons referred as controls, and utility components expose a specific subset of functions used in other components.  Other common types of components are those that are resource intensive, not frequently accessed, and must be activated using the just-in-time (JIT) approach.  Many components are invisible which are distributed in enterprise business applications and internet web applications such as Enterprise JavaBean (EJB), .NET components, and CORBA components. Characteristics of Components  Reusability − Components are usually designed to be reused in different situations in different applications. However, some components may be designed for a specific 169 CU IDOL SELF LEARNING MATERIAL (SLM)

task.  Replaceable − Components may be freely substituted with other similar components.  Not context specific − Components are designed to operate in different environments and contexts.  Extensible − A component can be extended from existing components to provide new behavior.  Encapsulated − A component depicts the interfaces, which allow the caller to use its functionality, and do not expose details of the internal processes or any internal variables or state.  Independent − Components are designed to have minimal dependencies on other components. Principles of Component−Based Design  A component-level design can be represented by using some intermediary representation (e.g. graphical, tabular, or text-based) that can be translated into source code. The design of data structures, interfaces, and algorithms should conform to well-established guidelines to help us avoid the introduction of errors.  The software system is decomposed into reusable, cohesive, and encapsulated component units.  Each component has its own interface that specifies required ports and provided ports; each component hides its detailed implementation.  A component should be extended without the need to make internal code or design modifications to the existing parts of the component.  Depend on abstractions component do not depend on other concrete components, which increase difficulty in expendability. 170 CU IDOL SELF LEARNING MATERIAL (SLM)

 Connectors connected components, specifying and ruling the interaction among components. The interaction type is specified by the interfaces of the components.  Components interaction can take the form of method invocations, asynchronous invocations, broadcasting, message driven interactions, data stream communications, and other protocol specific interactions.  For a server class, specialized interfaces should be created to serve major categories of clients. Only those operations that are relevant to a particular category of clients should be specified in the interface.  A component can extend to other components and still offer its own extension points. It is the concept of plug-in based architecture. This allows a plugin to offer another plugin API. Fig 9.4 Component based design Component-Level Design Guidelines  Creates naming conventions for components that are specified as part of the architectural model and then refines or elaborates as part of the component-level model.  Attains architectural component names from the problem domain and ensures that they have meaning to all stakeholders who view the architectural model. 171 CU IDOL SELF LEARNING MATERIAL (SLM)

 Extracts the business process entities that can exist independently without any associated dependency on other entities.  Recognizes and discover these independent entities as new components.  Uses infrastructure component names that reflect their implementation-specific meaning.  Models any dependencies from left to right and inheritance from top (base class) to bottom (derived classes).  Model any component dependencies as interfaces rather than representing them as a direct component-to-component dependency. Conducting Component-Level Design  Recognizes all design classes that correspond to the problem domain as defined in the analysis model and architectural model.  Recognizes all design classes that correspond to the infrastructure domain.  Describes all design classes that are not acquired as reusable components, and specifies message details.  Identifies appropriate interfaces for each component and elaborates attributes and defines data types and data structures required to implement them.  Describes processing flow within each operation in detail by means of pseudo code or UML activity diagrams.  Describes persistent data sources (databases and files) and identifies the classes required to manage them.  Develop and elaborates behavioral representations for a class or component. This can be done by elaborating the UML state diagrams created for the analysis model and by examining all use cases that are relevant to the design class. 172 CU IDOL SELF LEARNING MATERIAL (SLM)

 Elaborates deployment diagrams to provide additional implementation detail.  Demonstrates the location of key packages or classes of components in a system by using class instances and designating specific hardware and operating system environment.  The final decision can be made by using established design principles and guidelines. Experienced designers consider all (or most) of the alternative design solutions before settling on the final design model. Advantages  Ease of deployment − As new compatible versions become available, it is easier to replace existing versions with no impact on the other components or the system as a whole.  Reduced cost − the use of third-party components allows you to spread the cost of development and maintenance.  Ease of development − Components implement well-known interfaces to provide defined functionality, allowing development without impacting other parts of the system.  Reusable − The use of reusable components means that they can be used to spread the development and maintenance cost across several applications or systems.  Modification of technical complexity − A component modifies the complexity through the use of a component container and its services.  Reliability − The overall system reliability increases since the reliability of each individual component enhances the reliability of the whole system via reuse.  System maintenance and evolution − Easy to change and update the implementation without affecting the rest of the system.  Independent − Independency and flexible connectivity of components. Independent 173 CU IDOL SELF LEARNING MATERIAL (SLM)

development of components by different group in parallel. Productivity for the software development and future software development. 9.4 OBJECT ORIENTED ARCHITECTURE The components of a system encapsulate data and the operations that must be applied to manipulate the data. The coordination and communication between the components are established via the message passing. 9.4.1 Layered architecture:  A number of different layers are defined with each layer performing a well-defined set of operations. Each layer will do some operations that becomes closer to machine instruction set progressively.  At the outer layer, components will receive the user interface operations and at the inner layers, components will perform the operating system interfacing (communication and coordination with OS) Fig 9.5 Layered Architecture 9.4.2 Object -oriented concepts Object oriented design works around the entities and their characteristics instead of functions involved in the software system. This design strategies focuses on entities and its 174 CU IDOL SELF LEARNING MATERIAL (SLM)

characteristics. The whole concept of software solution revolves around the engaged entities. Let us see the important concepts of Object Oriented Design:  Objects - All entities involved in the solution design are known as objects. For example, person, banks, company and customers are treated as objects. Every entity has some attributes associated to it and has some methods to perform on the attributes.  Classes - A class is a generalized description of an object. An object is an instance of a class. Class defines all the attributes, which an object can have and methods, which defines the functionality of the object.  In the solution design, attributes are stored as variables and functionalities are defined by means of methods or procedures.  Encapsulation - In OOD, the attributes (data variables) and methods (operation on the data) are bundled together is called encapsulation. Encapsulation not only bundles important information of an object together, but also restricts access of the data and methods from the outside world. This is called information hiding.  Inheritance - OOD allows similar classes to stack up in hierarchical manner where the lower or sub-classes can import, implement and re-use allowed variables and methods from their immediate super classes. This property of OOD is known as inheritance. This makes it easier to define specific class and to create generalized classes from specific ones.  Polymorphism - OOD languages provide a mechanism where methods performing similar tasks but vary in arguments, can be assigned same name. This is called polymorphism, which allows a single interface performing tasks for different types. Depending upon how the function is invoked, respective portion of the code gets executed. 175 CU IDOL SELF LEARNING MATERIAL (SLM)

9.4.3 Design Process  Software design process can be perceived as series of well-defined steps. Though it varies according to design approach (function oriented or object oriented, yet It may have the following steps involved:  A solution design is created from requirement or previous used system and/or system sequence diagram.  Objects are identified and grouped into classes on behalf of similarity in attribute characteristics.  Class hierarchy and relation among them is defined.  Application framework is defined. 9.3 SUMMARY  Software design is the process of envisioning and defining software solutions to one or more sets of problems. One of the main components of software design is the software requirements analysis (SRA). SRA is a part of the software development process that lists specifications used in software engineering.  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 yields three levels of results: 176 CU IDOL SELF LEARNING MATERIAL (SLM)

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.  Back in time, all software’s are meant to be executed sequentially. By sequential execution we mean that the coded instruction will be executed one after another implying only one portion of program being activated at any given time. Say, a software has multiple modules, then only one of all the modules can be found active at any time of execution.  In software design, concurrency is implemented by splitting the software into multiple independent units of execution, like modules and executing them in parallel. In other words, concurrency provides capability to the software to execute more than one part of code in parallel to each other.  It is necessary for the programmers and designers to recognize those modules, which can be made parallel execution. 9.4 KEY WORDS/ABBREVIATIONS  Design level: the design decomposition of the software item; e.g., system, subsystem, program or module.  Design standards: standards that describe the characteristics of a design or a design 177 CU IDOL SELF LEARNING MATERIAL (SLM)

description of data or program components.  Equivalence class partitioning: partitioning the input domain of a program into a finite number of classes [sets], to identify a minimal set of well selected test cases to represent these classes. There are two types of input equivalence classes, valid and invalid. See: testing, functional.  File maintenance: the activity of keeping a file up to date by adding, changing, or deleting data.  Functional requirement: a requirement that specifies a function that a system or system component must be able to perform. 9.5 LEARNING ACTIVITY 1. Design Object Oriented software. __________________________________________________________________________ __________________________________________________________________________ 2. How to Implement Effective Modular Design? __________________________________________________________________________ __________________________________________________________________________ 9.6 UNIT END QUESTIONS (MCQ AND DESCRIPTIVE) A. Descriptive Types Questions 1. Illustrate architectural design to represents the design of software. 2. Take any non-object-oriented program that you have written with approximately 50 to300 lines of code. Write a flowchart for this program Explain in your own words the purpose Data design? 3. Identify the architecture used when input data to be transformed into output data through a series of computational manipulative components? Explain it detail. 178 CU IDOL SELF LEARNING MATERIAL (SLM)

4. Identify design provides a higher level of abstraction and divides the problem into sub- problems, associated with component partitions discuss it detail? 5. State design strategies focus on entities and its characteristics. B. Multiple Choice Questions 1. Which is the first step in the software development life cycle? (a) Analysis (b) Design (c) Problem/Opportunity Identification (d) Development and Documentation 2. Which tool is use for structured designing? (a) Program flowchart (b) Structure chart (c) Data-flow diagram (d) Module 3. A step by step instruction used to solve a problem is known as (a) Sequential structure (b) A List (c) A plan (d) An Algorithm 4. In the Analysis phase, the development of the ____________ occurs, which is a clear statement of the goals and objectives of the project. (a) documentation (b) flowchart (c) program specification (d) design 5. Actual programming of software code is done during the ____________ step in the SDLC. (a) Maintenance and Evaluation 179 CU IDOL SELF LEARNING MATERIAL (SLM)

(b) Design (c) Analysis (d) Development and Documentation Answers 1. (c), 2. (b), 3. (d), 4. (c), 5. (d) 9.7 REFERENCES  Pressman R.S. (2009). Software Engineering - A Practitioner’s Approach. New Delhi: MGH Publications.  Mall R. (2003). Fundamentals of Software Engineering. New Delhi: PHI  Jalote P. (2019). An Integrated Approach to Software Engineering. New Delhi: Narosa Publications.  Summerville I. (2013). Software Engineering. New Delhi: Pearson Education.  Software Engineering, Sixth Edition, 20~1, Ian Sommerville; Pearson Education.  Encyclopedia of software engineering” bylaplante laplante  Software engineering 1st edition” by Udit Agarwal  http://selab.csuohio.edu/~nsridhar/teaching/fall07/eec521/slides/  Lecture08.pdf http://www.avatto.com/exam/software-engineering-coupling-65.html  http://www.math-cs.gordon.edu/courses/cps122/lectures-2013/design  www.slideshare.net/arnoldindia/structure-chart  https://www.myarchicad.com/  “Algebraic methodology and software technology” by grigore rosu and jose 180 CU IDOL SELF LEARNING MATERIAL (SLM)

meseguer  “Fundamentals of software engineering, 2/e 2nd edition” by carlo ghezzi  An integrated hardware/software design methodology for signal processing systems Li L. Sau C.[...]Bhattacharyya S. S.  A survey of experienced user perceptions about software design patterns Zhang C. 181 CU IDOL SELF LEARNING MATERIAL (SLM)

UNIT 10 TESTING FUNDAMENTALS 182 Structure 10.0. Learning Objectives 10.1. Introduction 10.2. Objectives, principles, Testability 10.3. Test cases 10.4. White box testing 10.5. Black box testing 10.6. Summary 10.7. Key Words/Abbreviations 10.8. Learning Activity 10.9. Unit End Questions (MCQ and Descriptive) 10.10. References 10.0 LEARNING OBJECTIVES After studying this unit, you will be able to:  Discuss the basic concepts of software testing  Explain test cases-white box and black box testing  Explain details of white box testing  Explain details of black box testing 10.1 INTRODUCTION CU IDOL SELF LEARNING MATERIAL (SLM)

Software Testing is the process of executing a program or system with the intent of finding errors. Or, it involves any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. Software is not unlike other physical processes where inputs are received and outputs are produced. Where software differs is in the manner in which it fails. Most physical systems fail in a fixed (and reasonably small) set of ways. By contrast, software can fail in many bizarre ways. Detecting all of the different failure modes for software is generally infeasible. Unlike most physical systems, most of the defects in software are design errors, not manufacturing defects. Software does not suffer from corrosion, wear-and-tear — generally it will not change until upgrades, or until obsolescence. So once the software is shipped, the design defects – or bugs – will be buried in and remain latent until activation. Software bugs will almost always exist in any software module with moderate size: not because programmers are careless or irresponsible, but because the complexity of software is generally intractable – and humans have only limited ability to manage complexity. It is also true that for any complex systems, design defects can never be completely ruled out. Software Testing is evaluation of the software against requirements gathered from users and system specifications. Testing is conducted at the phase level in software development life cycle or at module level in program code. Software testing comprises of Validation and Verification. Software Testing Definition according to ANSI/IEEE 1059 standard – A process of analyzing a software item to detect the differences between existing and required conditions (i.e., defects) and to evaluate the features of the software item. 10.2 OBJECTIVES, PRINCIPLES, TESTABILITY Software Testing has different goals and objectives. The major objectives of Software testing are as follows:  Finding defects which may get created by the programmer while developing the software.  Gaining confidence in and providing information about the level of quality.  To prevent defects. 183 CU IDOL SELF LEARNING MATERIAL (SLM)

 To make sure that the end result meets the business and user requirements.  To ensure that it satisfies the BRS that is Business Requirement Specification and SRS that is System Requirement Specifications.  To gain the confidence of the customers by providing them a quality product. Software testing helps in finalizing the software application or product against business and user requirements. It is very important to have good test coverage in order to test the software application completely and make it sure that it’s performing well and as per the specification while determining the test coverage the test cases should be designed well with maximum possibilities of finding the errors or bugs. The test cases should be very effective. This objective can be measured by the number of defects reported per test cases. Higher the number of the defects reported the more effective are the test cases. Once the delivery is made to the end users or the customers they should be able to operate it without any complaints. In order to make this happen the tester should know as how the customers are going to use this product and accordingly they should write down the test scenarios and design the test cases. This will help a lot in fulfilling the entire customer’s requirements. Software testing makes sure that the testing is being done properly and hence the system is ready for use. Good coverage means that the testing has been done to cover the various areas like functionality of the application, compatibility of the application with the OS, hardware and different types of browsers, performance testing to test the performance of the application and load testing to make sure that the system is reliable and should not crash or there should not be any blocking issues. It also determines that the application can be deployed easily to the machine and without any resistance. Hence the application is easy to install, learn and use. Principles  Testing shows presence of defects  Exhaustive testing is not possible  Early testing 184 CU IDOL SELF LEARNING MATERIAL (SLM)

 Defect clustering  Pesticide paradox  Testing is context dependent  Absence of errors fallacy Testability- You might naively think all software is equally easy or hard to test. But you only have to look at how developers write unit tests to realize this isn’t so. Without suitable hooks for testing, many functions can only be tested implicitly by calling them from somewhere else and inspecting the results. Such functions are not very testable. But a well- designed function will include its own unit tests. These allow you to verify for certain that the function is working correctly. In effect, this is making the function testable. Further up the testing hierarchy, things become less clear-cut. Here, testability is about two things. Firstly, can you actually test the software, and secondly, how likely is it that your tests will reveal any bugs. The following diagram shows how this relates to the testability of your application. Fig 10.1 Testability For functional UI testing, there are some real challenges for both manual and automated tests. Let’s look at these in more detail before then exploring ways you can make your overall 185 CU IDOL SELF LEARNING MATERIAL (SLM)

application more testable. Challenges for automated testing Automated testing involves getting a computer to interact with your UI and replicate the actions of a real user. Things like selecting items on the screen, clicking on buttons, entering data in form fields, etc. The majority of test automation tools use some form of scripting to achieve this. These scripts first select an element in your UI, and then perform some action on that element. (NB, in well-designed tests, this action may simply be verifying the correct element is in the correct place on screen). Most test automation systems are based on a scripting language, such as JavaScript. JavaScript can select elements on the page in several ways. These include (in order of complexity) CSS selectors (e.g. Tag, ID, Class, attribute), DOM-specific (e.g. getElementById, getElementByName), and XPath. The problem is, with the possible exception of XPath, all these selectors can be ambiguous. This directly leads to the biggest bane of every test automation engineer’s life: test maintenance. Each time you make a change to your UI, it risks changing the selectors. Even simple CSS changes can have an effect. As a result, every change will break some or all your tests, requiring your test scripts to be rewritten. A related issue is the order in which selectors appear on the page. Scripting languages are relatively dumb. So, the first element that matches the selector will be the element it chooses. This can cause problems when your dev team decides to clean up their codebase. And again, this triggers the need for additional test maintenance and reduces software testability. Challenges for manual testing Manual testers have one key advantage over test automation engineers – they are human and therefore intelligent. This means that things, like restyling your site, moving elements on the page and even changing button names, shouldn’t worry them. However, they still face some real issues. For a start, they will generally be performing tests in a static location. Many sites and applications rely on geo location information, which is hard to test. Another key problem is application state. A real-life user quickly builds up a complex application state. 186 CU IDOL SELF LEARNING MATERIAL (SLM)

Being able to replicate this with manual tests can be time-consuming and hard. Repeating it test-after-test is even harder. The test data problem One problem is common to both manual and automatic testing – test data. If you are going to test your system properly, you need suitable test data. You might just use a copy of your real customer data. However, this has problems. If your system handles sensitive data (e.g. HIPAA or banking data), you can’t just allow anyone to have access to this data. Equally, if you have a new system you may not have any test data yet. In both these cases, you will end up having to create fake test data. That might sound easy enough, but it comes with a number of problems which we will explore later. Improving testability Below the system level in the testing hierarchy, improving software testability is largely about improving your code. This will involve things like adding explicit unit tests, utilizing tools that measure test coverage, code reviews, and the use of consistent code style. At the integration test stage, it involves understanding how each subsystem should function and may involve creating code to test for this. Where things get interesting is at the system testing stage. Making your UI more testable So, let’s look at what can you do to make your UI more testable. The following list is by no means exhaustive but shows you some of the ways you can improve matters. Better and consistent element naming Your developers can improve software testability if they simply make sure every element in the UI is correctly, predictably and uniquely named. This is a challenge in large projects where you may have big teams of frontend engineers. It is also particularly challenging when developing UIs for different platforms. Adding tools for testers 187 CU IDOL SELF LEARNING MATERIAL (SLM)

Manual testing will be much simpler if you build in tools specifically for this. For instance, you might make it simple for the application to adjust its apparent location. You might also create tools that make it easy to place the application into a known state. 10.3 TEST CASES Test case: White box testing The testing can be done at system, integration and unit levels of software development. One of the basic goals of white box testing is to verify a working flow for an application. It involves testing a series of predefined inputs against expected or desired outputs so that when a specific input does not result in the expected output, you have encountered a bug. To give you a simplified explanation of white box testing, we have divided it into two basic steps. This is what testers do when testing an application using the white box testing technique: Step 1 Understand the Source Code The first thing a tester will often do is learn and understand the source code of the application. Since white box testing involves the testing of the inner workings of an application, the tester must be very knowledgeable in the programming languages used in the applications they are testing. Also, the testing person must be highly aware of secure coding practices. Security is often one of the primary objectives of testing software. The tester should be able to find security issues and prevent attacks from hackers and naive users who might inject malicious code into the application either knowingly or unknowingly. Step 2 Create Test Cases and Execute The second basic step to white box testing involves testing the application's source code for proper flow and structure. One way is by writing more code to test the application's source code. The tester will develop little tests for each process or series of processes in the application. This method requires that the tester must have intimate knowledge of the code and is often done by the developer. Other methods include Manual Testing, trial, and error 188 CU IDOL SELF LEARNING MATERIAL (SLM)

testing and the use of testing tools as we will explain further on in this article. Fig 10.2 White box testing White box Testing Example Step-by-Step White Box Testing Example With that, let’s sink our teeth into a simple example of white box testing. For this purpose, let’s consider the following sample journey: A customer needs to transfer money to a friend who lives abroad. They’re going to use the mobile banking service provided by their bank to do this. Step 1: Identify the feature, component, program to be tested  Zero in on what you want to test.  When it comes to white box testing, the smaller your target system component, the better it is. Given what we’re trying to achieve – test all possible scenarios and cases for a given feature – individually testing individual features helps you focus on a small enough area of the code. 189 CU IDOL SELF LEARNING MATERIAL (SLM)

 A narrower focus also implies the ability to be more thorough. Remember, in a lot of the cases, you’re doing white box testing mainly because that specific system, feature, component is critical and needs to be tested through and through to guarantee it works as expected.  “A narrower focus also implies the ability to be more thorough.”  So, you should try and identify the smallest logical module or component for the system being tested, and work on this first. When you’re finished testing this module, you can move on to the next one.  Taking on a larger scope  Yes – it is possible that you’d take on white box testing for entire systems. Where the system involved is critical, draping it in white box testing will give you a high degree of confidence about code quality and resilience.  However, you need to weigh the effort involved versus the benefits derived. white box Testing is often labour intensive and will consume considerable resource. So it is important to balance effort with need.  “White box Testing is often labour intensive and will consume considerable resource. So it is important to balance effort with need.” Step 2: Plot all possible paths in a flowgraph  This step covers a big portion of your preparation to plan and execute white box testing successfully.  As with any effort – be it development or testing – understanding ‘Scope’ is paramount.  And, we already know that Path Coverage provides a comprehensive solution to Test coverage.  Here, we’re trying to understand all the possible paths that can be tested for a given feature, component, module… Identifying all possible paths helps in writing test cases to cover each one of them. And the best way to do this, is to draw a flowgraph that brings out these paths. 190 CU IDOL SELF LEARNING MATERIAL (SLM)

Consider the example below: Fig 10.3 Test case example Obviously, transferring funds from your bank account isn’t this simple. Sure, for some of us it can feel like it, but that’s because we don’t normally face the exceptions that quite a few others encounter when attempting to move money. Having said that, this Simple flowgraph will do nicely to demonstrate white box Testing.  To complete the flow graph, you may need to refer to the following:  User journeys, use cases  Program specifications  Technical specifications, pseudocode Step 3: Identify all possible paths from the flowgraph 191 CU IDOL SELF LEARNING MATERIAL (SLM)

Now, as you can see from Figure, there are two possible paths for this journey:  1, 2, 3, 5, 6, 7 and  1, 2, 3, 4, 6, 7 Being a simple example, only two paths exist to this journey. Nevertheless, you get the idea. Identify every permutation and combination for how the journey could flow from start to end. Identify any midway drop off points. And you’re all set. Step 4: Write Test Cases to cover every single path on the flowgraph When you have all available paths plotted on the flowgraph, then go ahead and write test cases to test each of these paths. When you have a bunch of test cases that you are confident will cover every single path, you’re ready to go to the execution phase. Step 5: Execute, rinse, and repeat You’re now ready to execute white box testing for the identified system, component or module. And you have the flow graph and Test Cases necessary to complete Testing. Test case: Black Box Testing Software testing method in which the functionalities of software applications are tested without having knowledge of internal code structure, implementation details and internal paths. Black Box Testing mainly focuses on input and output of software applications and it is entirely based on software requirements and specifications. It is also known as Behavioral Testing. 192 CU IDOL SELF LEARNING MATERIAL (SLM)

Fig 10.4 Black box testing The above Black-Box can be any software system you want to test. For Example, an operating system like Windows, a website like Google, a database like Oracle or even your own custom application. Under Black Box Testing, you can test these applications by just focusing on the inputs and outputs without knowing their internal code implementation How to do Black Box Testing Here are the generic steps followed to carry out any type of Black Box Testing.  Initially, the requirements and specifications of the system are examined.  Tester chooses valid inputs (positive test scenario) to check whether SUT processes them correctly. Also, some invalid inputs (negative test scenario) are chosen to verify that the SUT is able to detect them.  Tester determines expected outputs for all those inputs.  Software tester constructs test cases with the selected inputs.  The test cases are executed.  Software tester compares the actual outputs with the expected outputs. Defects if any are fixed and re-tested. Examples of Black Box Testing The example given below throws light on how the techniques of this testing can be used to test the specific software with given inputs While considering a shopping scenario,  Shop for $500 and receive a discount of 5%  Shop for $1000 and receive a discount of 7% 193 CU IDOL SELF LEARNING MATERIAL (SLM)

 Shop for $1500 or more and receive a discount of 10%  With the help of Equivalence partitioning technique of this testing, it is possible to divide inputs as four partitions, amount less than 0, 0 – 500, 501 – 1000, 1001 – 1500 and so on. The details such as the maximum limit for shopping and the product details will not be considered by this testing technique.  When boundary value is added to the partitions, the boundary values will be 0, 500, 501, 1000, 1001 and 1500. With the BVA technique, the lower and upper values are usually tested, so values like -1, 1 and 499 will be included. Such values will help in explaining the behavior of the input values in software.  According to State Transition Testing technique of Black box testing, when a shopper shops above $1500 two times in a month, their status gets changed from Gold to Platinum, and if he does not shop for the next 2 months, the status gets back to Gold. Using further test cases, it is possible for the tester to such complex track. 10.4 WHITE BOX TESTING White-box testing or glass-box testing is a test case design method that uses the control structure of the procedural design to obtain test cases. Using this methodology, a software engineer can come up with test cases that guarantee that all independent paths within a module have been executing all loops at their boundaries and within them; and exercise internal data structures to ensure their validity. The reason of conducting white-box testing largely depends upon the nature of defects in software: Logic errors and incorrect assumptions are inversely proportional to the probability that a program path will be executed. We often believe that a logical path is not likely to be executed when, in fact, it may be executed on a regular basis. Typographical errors are random. Contrary to black-box testing, software is viewed as a white-box, or glass-box in white-box testing, as the structure and flow of the software under test are visible to the tester. Testing plans are made according to the details of the software implementation, such as programming language, logic, and styles. Test cases are derived from the program structure. White-box testing is also called 194 CU IDOL SELF LEARNING MATERIAL (SLM)

glass-box testing, logic-driven testing or design-based testing There are many techniques available in white-box testing, because the problem of intractability is eased by specific knowledge and attention on the structure of the software under test. The intention of exhausting some aspect of the software is still strong in white-box testing, and some degree of exhaustion can be achieved, such as executing each line of code at least once (statement coverage), traverse every branch statements (branch coverage), or cover all the possible combinations of true and false condition predicates (Multiple condition coverage). Control- flow testing, loop testing, and data-flow testing, all maps the corresponding flow structure of the software into a directed graph. Test cases are carefully selected based on the criterion that all the nodes or paths are covered or traversed at least once. By doing so we may discover unnecessary “dead” code — code that is of no use, or never get executed at all, which cannot be discovered by functional testing. In mutation testing, the original program code is perturbed and many mutated programs are created, each contains one fault. Each faulty version of the program is called a mutant. Test data are selected based on the effectiveness of failing the mutants. The more mutants a test case can kill, the better the test case is considered. The problem with mutation testing is that it is too computationally expensive to use. The boundary between black-box approach and white-box approach is not clear-cut. Many testing strategies mentioned above, may not be safely classified into black- box testing or white-box testing. It is also true for transaction-flow testing, syntax testing, finite-state testing, and many other testing strategies not discussed in this text. One reason is that all the above techniques will need some knowledge of the specification of the software under test. Another reason is that the idea of specification itself is broad — it may contain any requirement including the structure, programming language, and programming style as part of the specification content. We may be reluctant to consider random testing as a testing technique. The test case selection is simple and straightforward: they are randomly chosen. Some very subtle errors can be discovered with low cost. And it is also not inferior in coverage than other carefully designed testing techniques. One can also obtain reliability estimate using random testing results based on operational profiles. White-box Testing Techniques White-box testing, sometimes called glass-box testing is a test case design method that uses 195 CU IDOL SELF LEARNING MATERIAL (SLM)

the control structure of the procedural design to derive test cases. Using white-box testing methods, the software engineer can derive test cases that: 1. Guarantee that all independent paths within a module have been exercised at least once 2. Exercise all logical decisions on their true and false sides 3. Execute all loops at their boundaries and within their operational bounds, and 4. Exercise internal data structures to ensure their validity. Basis Path Testing -Basis path testing is a white-box testing technique first proposed by Tom McCabe. The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing. Flow Graph Notation- The flow graph depicts logical control flow which is used to depict the program control structure Fig 10.5 Flow Graph Notation Referring to the figure, each circle, called a flow graph node, represents one or more procedural statements. A sequence of process boxes and a decision diamond can map into a single node. The arrows on the flow graph, called edges or links, represent flow of control and are analogous to flowchart arrows. An edge must terminate at a node, even if the node does not represent any procedural statements (e.g., see the symbol for the if-then-else construct). Areas bounded by edges and nodes are called regions. When counting regions, 196 CU IDOL SELF LEARNING MATERIAL (SLM)

we include the area outside the graph as a region. Cyclomatic Complexity/Independent Program Path Cyclomatic complexity is software metric that provides a quantitative measure of the logical complexity of a program. When used in the context of the basis path testing method, the value computed for cyclomatic complexity defines the number of independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once. An independent path is any path through the program that introduces at least one new set of processing statements or a new condition. When stated in terms of a flow graph, an independent path must move along at least one edge that has not been traversed before the path is define Fig 10.6 Independent Program Path(a) 197 CU IDOL SELF LEARNING MATERIAL (SLM)

. Fig 10.6 Independent Program Path (b) Fig 10.6 Independent Program Path (c) Example: A set of independent paths for the flow graph illustrated in Figure 10.6 (b) is: Path 1: 1-11 Path 2: 1-2-3-4-5-10-1-11 198 CU IDOL SELF LEARNING MATERIAL (SLM)

Path 3: 1-2-3-6-8-9-10-1-11 Path 4: 1-2-3-6-7-9-10-1-11 10.5 BLACK BOX TESTING Black-box testing or behavioral testing, mainly focuses on the functional requirements of the software. It enables the software engineer to develop a set of inputs that can fully involve all the functional requirements for a program. It is not an alternative approach to white-box testing. Rather, it completes the testing by uncovering different types of errors than the white-box approach Fig 10.7 Black box testing This approach attempts to find errors in the following categories: 1. Incorrect or missing functions, 2. Interface related errors, 3. Errors in data structures or database accesses, 4. Performance related errors and 5. Initialization and termination errors. Black box testing is a software testing techniques in which functionality of the software under test (SUT) is tested without looking at the internal code structure, implementation details and knowledge of internal paths of the software. Black-box Testing Techniques Black-box testing, also called behavioral testing, focuses on the functional requirements of the software. That is, black-box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. Black-box 199 CU IDOL SELF LEARNING MATERIAL (SLM)