Software Engineering Unit 3 Key Concepts and Practices

Software engineering is a dynamic field at the intersection of computer science, engineering principles, and business practices. It encompasses the design, development, testing, and maintenance of software systems that power virtually every aspect of modern life. From the operating systems that run our devices to the applications that facilitate communication, commerce, and entertainment, software engineering is integral to our daily experiences.

### Foundations of Software Engineering

At its core, software engineering relies on principles derived from computer science, mathematics, and engineering. It involves systematic approaches to software development, including requirements analysis, design, implementation, testing, deployment, and maintenance. These processes are guided by methodologies such as agile, waterfall, and DevOps, each offering distinct advantages depending on the project's scale, complexity, and requirements.

### Development Lifecycle

The software development lifecycle (SDLC) outlines the stages through which software progresses from concept to deployment and beyond. Requirements gathering involves eliciting and documenting user needs and system functionality. Design transforms these requirements into a blueprint that outlines system architecture, data structures, and algorithms.

Implementation, the phase where code is written, brings designs to life. This is followed by rigorous testing to ensure software meets functional, performance, and security criteria. Deployment involves making the software operational in its intended environment, while maintenance ensures ongoing updates, bug fixes, and enhancements to address evolving user needs and technological advancements.

### Key Concepts and Practices

**1. Design Patterns:** Design patterns provide reusable solutions to common software design problems. Examples include Singleton, Factory, and Observer patterns, which improve code flexibility, maintainability, and scalability.

**2. Algorithms and Data Structures:** Efficient algorithms and data structures are fundamental to software performance. Sorting algorithms like QuickSort and data structures like hash tables optimize operations such as searching and data retrieval.

**3. Version Control:** Version control systems like Git enable collaborative development by tracking changes to source code. Branching and merging features facilitate concurrent work on different code versions while maintaining a cohesive codebase.

**4. Testing and Quality Assurance:** Testing strategies include unit testing, integration testing, and acceptance testing, ensuring software reliability and functionality. Automated testing frameworks like JUnit and Selenium streamline testing processes and detect defects early in development cycles.

**5. Security:** Software security is paramount to protect against vulnerabilities and cyber threats.

1. Noida Institute of Engineering and Technology, Greater Noida Software Design 3/30/2024 1 Unit: 3 Subject Name: Software Engineering (ACSEH0603) Course Details B.Tech .(CSE R ) 6 th Sem

2. Software Design is the process of transforming user requirements into a suitable form, which helps the programmer in software coding and implementation. During the software design phase, the design document is produced, based on the customer requirements as documented in the SRS document. Hence, this phase aims to transform the SRS document into a design document. The following items are designed and documented during the design phase: Different modules are required. Control relationships among modules. Interface among different modules. Data structure among the different modules. Algorithms are required to be implemented among the individual modules.   3/30/2024 2 What Is Design?

3. Objectives of Software Design:  Correctness:   A good design should be correct i.e., it should correctly implement all the functionalities of the system. Efficiency:   A good software design should address the resources, time, and cost optimization issues. Flexibility:  A good software design should have the ability to adapt and accommodate changes easily. It includes designing the software in a way, that allows for modifications, enhancements, and scalability without requiring significant rework or causing major disruptions to the existing functionality. Understandability:   A good design should be easily understandable, it should be modular, and all the modules are arranged in layers. Completeness:   The design should have all the components like data structures, modules, and external interfaces, etc. Maintainability:   A good software design aims to create a system that is easy to understand, modify, and maintain over time. This involves using modular and well-structured design principles e.g.,(employing appropriate naming conventions and providing clear documentation). Maintainability in software Design also enables developers to fix bugs, enhance features, and adapt the software to changing requirements without excessive effort or introducing new issues. 3/30/2024 3 Objectives of Software Design: 

4. 3/30/2024 4 Software Design Concepts:  Concepts are defined as a principal idea or invention that comes into our mind or in thought to understand something. The  software design concept  simply means the idea or principle behind the design. It describes how you plan to solve the problem of designing software, the logic, or thinking behind how you will design software. It allows the software engineer to create the model of the system or software or product that is to be developed or built. The software design concept provides a supporting and essential structure or model for developing the right software. There are many concepts of software design and some of them are given below: 

5. 3/30/2024 5 Software Design Concepts: 

6. 3/30/2024 6 Design process

7. 3/30/2024 7 Points should be considered while Designing Software:  Abstraction-  ( Hide Irrelevant data  ) Abstraction simply means to hide the details to reduce complexity and increases efficiency or quality. Different levels of Abstraction are necessary and must be applied at each stage of the design process so that any error that is present can be removed to increase the efficiency of the software solution and to refine the software solution. The solution should be described in broad ways that cover a wide range of different things at a higher level of abstraction and a more detailed description of a solution of software should be given at the lower level of abstraction. Modularity- (subdivide the system)   Modularity simply means dividing the system or project into smaller parts to reduce the complexity of the system or project. In the same way, modularity in design means subdividing 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 in design has now become a trend and is also important. If the system contains fewer components then it would mean the system is complex which requires a lot of effort (cost) but if we are able to divide the system into components then the cost would be small. 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.

8. 3/30/2024 8 Points should be considered while Designing Software:  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 can’t be accessed by any other modules. Refactoring-( Reconstruct something ) Refactoring simply means reconstructing something in such a way that it does not affect the behavior of any other features. Refactoring in software design means reconstructing the design to reduce complexity and simplify it without impacting the behavior or its functions. Fowler has defined refactoring as “the process of changing a software system in a way that it won’t impact the behavior of the design and improves the internal structure”.

9. 3/30/2024 9 Different levels of Software Design:  There are three different levels of software design. They are:  Architectural Design:   The architecture of a system can be viewed as the overall structure of the system & the way in which structure provides conceptual integrity of the system. The architectural design identifies the software as a system with many components interacting with each other. At this level, the designers get the idea of the proposed solution domain.    Preliminary or high-level design:   Here the problem is decomposed into a set of modules, the control relationship among various modules identified, and also the interfaces among various modules are identified. The outcome of this stage is called the program architecture. Design representation techniques used in this stage are structure chart and UML.    Detailed design:   Once the high-level design is complete, a detailed design is undertaken. In detailed design, each module is examined carefully to design the data structure and algorithms. The stage outcome is documented in the form of a module specification document. 

10. 3/30/2024 10 Principles of Software Design Software Design  is also a process to plan or convert the software requirements into a step that are needed to be carried out to develop a software system. There are several principles that are used to organize and arrange the structural components of Software design. Software Designs in which these principles are applied affect the content and the working process of the software from the beginning.

11. 3/30/2024 11 Design principles : Design principles :

12. Should not suffer from “Tunnel Vision” –  While designing the process, it should not suffer from “tunnel vision” which means that is should not only focus on completing or achieving the aim but on other effects also. Traceable to analysis model –  The design process should be traceable to the analysis model which means it should satisfy all the requirements that software requires to develop a high-quality product. Should not “Reinvent The Wheel” –  The design process should not reinvent the wheel that means it should not waste time or effort in creating things that already exist. Due to this, the overall development will get increased. Minimize Intellectual distance –  The design process should reduce the gap between real-world problems and software solutions for that problem meaning it should simply minimize intellectual distance. Design is not coding and coding is not design –  Design means describing the logic of the program to solve any problem and coding is a type of language that is used for the implementation of a design. 3/30/2024 12 Principles of Design

13. 7 Exhibit uniformity and integration –  The design should display uniformity which means it should be uniform throughout the process without any change. Integration means it should mix or combine all parts of software i.e. subsystems into one system. 8 Accommodate change –  The software should be designed in such a way that it accommodates the change implying that the software should adjust to the change that is required to be done as per the user’s need. 9 Degrade gently –  The software should be designed in such a way that it degrades gracefully which means it should work properly even if an error occurs during the execution. 10 Assessed or quality –  The design should be assessed or evaluated for the quality meaning that during the evaluation, the quality of the design needs to be checked and focused on. 11 Review to discover errors –  The design should be reviewed which means that the overall evaluation should be done to check if there is any error present or if it can be minimized. 3/30/2024 13 Principles of Design

14. Modularity is the single attribute of software that allows a program to be intellectually manageable. It enhances design clarity, which in turn eases implementation, debugging, testing, documenting and maintenance of the software product. In Software engineering, Modularity refers to the extent to which a software / web application may be divided into smaller modules. 3/30/2024 14 Modularity (CO3)

15. Modularization: Modularization is the process of dividing a software system into multiple independent modules where each module works independently. There are many advantages of Modularization in software engineering. Some of these are given below: Easy to understand the system. System maintenance is easy. A module can be used many times as their requirements. No need to write it again and again. 3/30/2024 15 Modularity (CO3)

16. Indian States Indian s tates were created based on language and cultural background in 1956 and abolished the system of provinces and princely states. 3/30/2024 16

17. Cohesion is a measure of the degree to which the elements of a module are functionally related. A strongly cohesive module implements functionality that is related to one feature of the solution and requires little or no interaction with other modules. It is the degree to which all elements directed towards performing a single task are contained in the component. Basically, cohesion is the internal glue that keeps the module together. A good software design will have high cohesion. 3/30/2024 17 Module Cohesion (CO3)

18. 3/30/2024 18 Module Cohesion (CO3)

19. 3/30/2024 19 Module Cohesion Cohesion : Strength of relations within modules

20. Functional cohesion Sequential cohesion Communication cohesion Procedural cohesion Temporal cohesion Logical cohesion Coincidental cohesion 3/30/2024 20 Types of Cohesion

21. 3/30/2024 21 Module Cohesion Logical Cohesion (Worst) Coincidental Cohesion Temporal Cohesion Procedural Cohesion Communicational Cohesion Sequential Cohesion Best (high) Functional Cohesion

22. 3/30/2024 22

23. Functional Cohesion: Every essential element for a single computation is contained in the component. A functional cohesion performs the task and functions. It is an ideal situation. Wedding arrangement done by many persons, module which control diff functions, track ball, cursor, pointer. Sequential Cohesion: Sequential is very imp and functions are part of sequence along with data dependency e.g Function 1 provides data and function 2 which process data f1- Radius, f2 – amount, f3- total cost. An element outputs some data that becomes the input for other element, i.e., data flow between the parts. Communicational Cohesion: In case of communication Cohesion different functions are operating on the same data structure. E.g push and POP . Two elements operate on the same input data or contribute towards the same output data. Example- update record in the database and send it to the printer. Procedural Cohesion: Here functions of a module are related to each other through a flow control i.e they are part of algorithm / procedure. E.g. File Access and open . First Checks the authentication second opens the File. Elements of procedural cohesion ensure the order of execution. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA. 3/30/2024 23 Types of Cohesion

24. Temporal Cohesion: Functions are related by fact that all task must be executed in same time span so there is flow control b/w functions. Two functions which catch the exception and second flash the error. E.g Fire and water Pipe System . A module connected with temporal cohesion all the tasks must be executed in the same time span. Logical Cohesion: All elements of a module perform similar or slightly similar operations e.g Input , output functions are kept in a file, Mouse, printer , Scanner functions are kept in a same module. The elements are logically related and not functionally. Ex- A component reads inputs from tape, disk, and network. All the code for these functions is in the same component. Operations are related, but the functions are significantly different. Coincidental Cohesion: It is such kind relation among the functions which are present in a module is random or coincidently. All students are readind g the same subject of different courses. The elements have no conceptual relationship other than location in source code. It is accidental and the worst form of cohesion. Ex- print next line and reverse the characters of a string in a single component. 3/30/2024 24 Types of Cohesion

25. Trick to remember Cohesion types: F irst S emester of C ollege P rovided T ough and L ong C urriculum. Or FSC P a T e L C   3/30/2024 25 Flowgraph of Cohesion Types

26. Coupling is the measure of the degree of interdependence between modules. Two modules with high coupling are strongly interconnected and thus, dependent on each other. Two modules with low coupling are not dependent on one another. 3/30/2024 26 Module Coupling (CO3) Uncoupled loosely coupled highly coupled

27. A good design will have low coupling. Thus, interfaces should be carefully specified in order to keep low value of coupling. Coupling is measured by the number of interconnections between modules. This can achieve in the following ways: * Controlling the number of parameters passing amongst modules. * Avoid passing undesired data to calling module. * Maintain parent/child relationship between calling and called modules. 3/30/2024 27 Module Coupling

28. Low coupling is desirable because high coupling leads to more errors and it makes debugging of errors very difficult. How modules are coupled or get dependent? When modules share data (Global data) or exchange data or they make calls to each other. 3/30/2024 28 Module Coupling

29. Data coupling Stamp coupling Control coupling External coupling Common coupling Content coupling 3/30/2024 29 Types of Coupling

30. Data Coupling When data of one module is passed to another module, this is called data coupling. e.g call by value money asked provided without knowing the storage location. No need to know how addition performed by calculator internally. Stamp Coupling When complete data structure is passed from 1 module to another . E.g Call by Reference by knowing the storage location money asked and provided by exact location where it is available. Drawback : The entire data structure is not required by receiving module only a part of data structure is required. 3/30/2024 30 Types of Coupling

31. Control Coupling Communication between modules occurs by passing control information OR a module controls the flow of another module. Eg : Flags, data that is set by 1 module is used by another module., Producer Consumer problem after a certain limit producer has to stop production in case consumer is not consuming no more. Signal System Train Signal System External Coupling Dependency of a module on another module which is present in a Software or Hardware external to the system. Eg : External Tools or devices that we use., Sharing of Data Bus, ROM and sharing screen is possible without reading and writing simultaneously no two users can do same task at a time in a shared devices. Screen sharing. Mobile screen sharing for number of users at a time. By external reasons two modules are dependent on each other like common narrow passage single railway track only one train can pass it other has to wait for track available idle. 3/30/2024 31 Types of Coupling

32. Common Coupling When t wo modules have common shared data/global data (accessed by both). Process synchronization by common global data, Critical section proble m , Deadlock Content Coupling It occurs when control is passed from one module to middle of another module OR a module changes data of another module . e.g Car and Engine without engine Car is of no use, Without body no use of sense organs. High Level of dependency is there Engine is a sub set of Car. 3/30/2024 32 Types of Coupling

33. 3/30/2024 33 Module Coupling Trick to remember Coupling types: D id S he C ontrol E xam of C ommon C ontent . Or DSC EC 2

34. 3/30/2024 34 Relationship between Cohesion & Coupling Coupling "  describes the relationships between modules , and " cohesion " describes the relationships within them. A reduction in interconnectedness between modules (or classes) is therefore achieved via a reduction in coupling.

35. 3/30/2024 35 Differentiate between Coupling and Cohesion Coupling Cohesion Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding. Coupling shows the relationships between modules. Cohesion shows the relationship within the module. Coupling shows the relative  independence  between the modules. Cohesion shows the module's relative  functional  strength. While creating, you should aim for low coupling, i.e., dependency among modules should be less. While creating you should aim for high cohesion, i.e., a cohesive component/ module focuses on a single function (i.e., single-mindedness) with little interaction with other modules of the system. In coupling, modules are linked to the other modules. In cohesion, the module focuses on a single thing.

36. 3/30/2024 36 Design Strategy  A good system design is to organize the program modules in such a way that are easy to develop and change. Structured design techniques help developers to deal with the size and complexity of programs. Software Engineering is the process of designing, building, testing, and maintaining software. The goal of software engineering is to create software that is reliable, efficient, and easy to maintain.

37. 3/30/2024 37 Design Strategy  Top-Down Design: This strategy starts with a high-level view of the system and gradually breaks it down into smaller, more manageable components. Bottom-Up Design: This strategy starts with individual components and builds the system up, piece by piece. Iterative Design: This strategy involves designing and implementing the system in stages, with each stage building on the results of the previous stage. Incremental Design: This strategy involves designing and implementing a small part of the system at a time, adding more functionality with each iteration. Agile Design: This strategy involves a flexible, iterative approach to design, where requirements and design evolve through collaboration between self-organizing and cross-functional teams.

38. 3/30/2024 38 Bottom-up approach: The design starts with the lowest level components and subsystems. By using these components, the next immediate higher-level components and subsystems are created or composed. The process is continued till all the components and subsystems are composed into a single component, which is considered as the complete system. The amount of abstraction grows high as the design moves to more high levels. 

39. 3/30/2024 39 Bottom-up approach:

40. 3/30/2024 40 Bottom-up approach: Advantages of Bottom-up approach: The economics can result when general solutions can be reused. It can be used to hide the low-level details of implementation and be merged with the top-down technique. Disadvantages of Bottom-up approach: It is not so closely related to the structure of the problem. High-quality bottom-up solutions are very hard to construct. It leads to the proliferation of ‘potentially useful’ functions rather than the most appropriate ones.

41. 3/30/2024 41 Top-down approach: Each system is divided into several subsystems and components. Each of the subsystems is further divided into a set of subsystems and components. This process of division facilitates forming a system hierarchy structure. The complete software system is considered a single entity and in relation to the characteristics, the system is split into sub-systems and components. The same is done with each of the sub-systems.  This process is continued until the lowest level of the system is reached. The design is started initially by defining the system as a whole and then keeps on adding definitions of the subsystems and components. When all the definitions are combined, it turns out to be a complete system. 

42. 3/30/2024 42 Top-down approach: Advantages of Top-down approach: The main advantage of the top-down approach is that its strong focus on requirements helps to make a design responsive according to its requirements. Disadvantages of Top-down approach: Project and system boundaries tend to be application specification-oriented. Thus, it is more likely that the advantages of component reuse will be missed. The system is likely to miss, the benefits of a well-structured, simple architecture. Hybrid Design: It is a combination of both top-down and bottom-up design strategies. In this, we can reuse the modules.

43. 3/30/2024 43 Top-down approach:

44. Design Notations 3/30/2024 44 Design Notations are primarily meant to be used during the process of design and are used to represent design or design decisions. For a function-oriented design, the design can be represented graphically or mathematically by the following:

45. 3/30/2024 45

46. Scope References Definitions Purpose of an SDD Design Description Information Content Design Description Organisation 3/30/2024 46 IEEE Recommended Practice for Software Design Descriptions (IEEE STD 1016-1998)

47. Function Oriented Design Function Oriented design is a method to software design where the model is decomposed into a set of interacting units or modules where each unit or module has a clearly defined function. Thus, the system is designed from a functional viewpoint. 3/30/2024 47

48. Focus is on Functions Functions  Subfunctions….and more subfunctions Emphasis on “What the system does?” VERB 3/30/2024 48 Function Oriented Design (FOD)

49. Focus is on Objects Parent Object  Child Object etc. Emphasis on “What the system consists of?” NOUN 3/30/2024 49 Object Oriented Design (OOD)

50. 3/30/2024 50 Difference between FOD and OOD (Banking Process)

51. The modularity focus of the online retail application example discussed above was on design-time modularity, or in other words the application’s logical design. Design-time/logical modularity is about structuring a system/codebase into self-contained, cohesive modules with minimum interconnections. Another form of modularity is runtime or physical modularity, which views modules as units of deployment and dependencies. It’s concerned with how the module constituents are packaged for deployment and/or managed at runtime. Java’s Modules feature which was added in Java 9, is an example of this form of modularity. OSGi is another example. 3/30/2024 51 Design-Time vs. Runtime Modularity

52. Design Notations Structure chart Pseudocode Flowcharts 3/30/2024 52 Function oriented design

53. Function oriented design is the result of focusing attention to the function of the program. This is based on the stepwise refinement. Stepwise refinement is based on the iterative procedural decomposition. Stepwise refinement is a top-down strategy where a program is refined as a hierarchy of increasing levels of details. The refinement of each module is done until we reach the statement level of our programming language. 3/30/2024 53 Function Oriented Design (CO3)

54. Structure Chart represent hierarchical structure of modules. It breaks down the entire system into lowest functional modules, describe functions and sub-functions of each module of a system to a greater detail. Structure Chart partitions the system into black boxes (functionality of the system is known to the users but inner details are unknown). Inputs are given to the black boxes and appropriate outputs are generated. 3/30/2024 54 Structure Chart (CO3)

55. Module It represents the process or task of the system. It is of three types. Control Module A control module branches to more than one sub module. Sub Module Sub Module is a module which is the part (Child) of another module. Library Module Library Module are reusable and invokable from any module. 3/30/2024 55 Symbols used in Structure Charts

56. 2. Conditional Call It represents that control module can select any of the sub module on the basis of some condition. 3/30/2024 56 Symbols used in Structure Charts

57. 3. Loop (Repetitive call of module) It represents the repetitive execution of module by the sub module. A curved arrow represents loop in the module. 3/30/2024 57 Symbols used in Structure Charts

58. 4. Data Flow It represents the flow of data between the modules. It is represented by directed arrow with empty circle at the end. 3/30/2024 58 Symbols used in Structure Charts

59. 5. Control Flow It represents the flow of control between the modules. It is represented by directed arrow with filled circle at the end. 3/30/2024 59 Symbols used in Structure Charts

60. 6. Physical Storage Physical Storage is that where all the information are to be stored. 3/30/2024 60 Symbols used in Structure Charts

61. Structure chart for an Email server 3/30/2024 61 Structure Chart Example

62. Pseudo code : It is a false code or a representation of code which can be understood by even a layman with some school level programming knowledge. Algorithm: It is an organized logical sequence of the actions or the approach towards a particular problem. 3/30/2024 62 Pseudo Codes

63. A pictorial representation of an algorithm is called a 'Flowchart' . In flowchart, the steps in the algorithm are represented in the form of different shapes of boxes and the logical flow is indicated by interconnecting arrows. 3/30/2024 63 Flow Charts

64. 1. Draw the flowchart to print the largest of any three numbers. 2. Draw the flowchart to print the factorial of a number. (Considering whole numbers) 3/30/2024 64 Flow Charts

65. 3/30/2024 65

66. Algorithm for finding factorial of a given number Step 1: Start Step 2: Read the input number from the user Step 2: Declare and initialize variables fact = 1 and i =  1 Step 4:  Repeat the loop until  i <=num –  fact = fact * i –  i =  i ++ Step 5:  Print fact to get the  Factorial  of a given number Step 6: Stop 3/30/2024 66

67. import java.util.Scanner ; class Factorial { public static void main(String[] args ){ Scanner sc = new Scanner(System.in); System.out.println ("Enter Number: "); int num = sc.nextInt (); int fact = 1; for(int i =1; i <= num ; i ++){ fact = fact * i ; } System.out.println ("Factorial of a given number is " + fact); } } 3/30/2024 67

68. Flowchart for Largest of three numbers: 3/30/2024 68

69. Pseudocode for largest of three numbers: Declare a variable a, b, c and largest as integer; Read the number a, b and c; max = a > b ? (a > c ? a : c) : (b > c ? b : c); print max; 3/30/2024 69

70. Implementation of largest of Three numbers in C #include<stdio.h> int main() { int a, b, c, max; printf ("Enter three numbers:"); printf ("\ na :"); scanf ("%d", & a); printf ("b:"); scanf ("%d", & b); printf ("c:"); scanf ("%d", & c); max = a > b ? (a > b ? a : c) : (b > c ? b : c); printf ("%d is the largest number.", max); } 3/30/2024 70

71. Object-Oriented Design In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities). The state is distributed among the objects, and each object handles its state data. For example, in a Library Automation Software, each library representative may be a separate object with its data and functions to operate on these data. 3/30/2024 71

72. 3/30/2024 72

73. Objects:  All entities involved in the solution design are known as objects. For example, person, banks, company, and users are considered as objects. Every entity has some attributes associated with 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. A class defines all the attributes, which an object can have and methods, which represents the functionality of the object. Messages:  Objects communicate by message passing. Messages consist of the integrity of the target object, the name of the requested operation, and any other action needed to perform the function. Messages are often implemented as procedure or function calls. Abstraction  In object-oriented design, complexity is handled using abstraction. Abstraction is the removal of the irrelevant and the amplification of the essentials. 3/30/2024 73

74. 4. Encapsulation:  Encapsulation is also called an information hiding concept. The data and operations are linked to a single unit. Encapsulation not only bundles essential information of an object together but also restricts access to the data and methods from the outside world. 5. Inheritance:  OOD allows similar classes to stack up in a hierarchical manner where the lower or sub-classes can import, implement, and re-use allowed variables and functions from their immediate super classes. This property of OOD is called an inheritance. This makes it easier to define a specific class and to create generalized classes from specific ones. 6. Polymorphism:  OOD languages provide a mechanism where methods performing similar tasks but vary in arguments, can be assigned the same name. This is known as polymorphism, which allows a single interface is performing functions for different types. Depending upon how the service is invoked, the respective portion of the code gets executed. 3/30/2024 74

75. Object-Oriented Design 3/30/2024 75

76. Object-Oriented Design 3/30/2024 76 The Subsystem Layer:  It represents the subsystem that enables software to achieve user requirements and implement technical frameworks that meet user needs. The Class and Object Layer:  It represents the class hierarchies that enable the system to develop using generalization and specialization. This layer also represents each object. The Message Layer:  This layer deals with how objects interact with each other. It includes messages sent between objects, method calls, and the flow of control within the system. The Responsibilities Layer:  It focuses on the responsibilities of individual objects. This includes defining the behavior of each class, specifying what each object is responsible for, and how it responds to messages.

77. Benefits of Object-Oriented Analysis and Design(OOAD) 3/30/2024 77 Improved modularity:  OOAD encourages the creation of small, reusable objects that can be combined to create more complex systems, improving the modularity and maintainability of the software. Better abstraction:  OOAD provides a high-level, abstract representation of a software system, making it easier to understand and maintain. Improved reuse:  OOAD encourages the reuse of objects and object-oriented design patterns, reducing the amount of code that needs to be written and improving the quality and consistency of the software. Improved communication:  OOAD provides a common vocabulary and methodology for software developers, improving communication and collaboration within teams. Reusability:  OOAD emphasizes the use of reusable components and design patterns, which can save time and effort in software development by reducing the need to create new code from scratch.

78. Benefits of Object-Oriented Analysis and Design(OOAD) 3/30/2024 78 Scalability:  OOAD can help developers design software systems that are scalable and can handle changes in user demand and business requirements over time. Maintainability:  OOAD emphasizes modular design and can help developers create software systems that are easier to maintain and update over time. Flexibility:  OOAD can help developers design software systems that are flexible and can adapt to changing business requirements over time. Improved software quality:  OOAD emphasizes the use of encapsulation, inheritance, and polymorphism, which can lead to software systems that are more reliable, secure, and efficient.

79. Importance of System Design Strategy: If any pre-existing code needs to be understood, organized, and pieced together. It is common for the project team to have to write some code and produce original programs that support the application logic of the system. 3/30/2024 79

80. 3/30/2024 80 Comparison Table of FOD vs OOD

81. 3/30/2024 81 Top down v/s B ottom U p A pproach TOP DOWN APPROACH BOTTOM UP APPROACH In this approach We focus on breaking up the problem into smaller parts. In bottom up approach, we solve smaller problems and integrate it as whole and complete the solution Mainly used by structured programming language such as COBOL, Fortran, C, etc. Mainly used by object oriented programming language such as C++, C#, Python. Each part is programmed separately therefore contain redundancy. Redundancy is minimized by using data encapsulation and data hiding. In this the communications is less among modules. In this module must have communication. It is used in debugging, module documentation, etc. It is basically used in testing. In top down approach, decomposition takes place. In bottom up approach composition takes place. In this top function of system might be hard to identify. In this sometimes we can not build a program from the piece we have started. In this implementation details may differ. This is not natural for people to assemble.

82. Calculating size using Function Point Metric. Control flow graph Cyclomatic complexity and its method of calculation. 3/30/2024 82 Software Measurement and Metrics

83. 3/30/2024 83 Function Point Metric (CO3) Function Point Analysis was initially developed by Allan J. Albrecht in 1979 at IBM and has been further modified by the International Function Point User’s Group (IFPUG). Allan J. Albrecht gave the initial definition. Functional Point Analysis gives a dimensionless number defined in function points which we have found to be an effective relative measure of function value delivered to our customer.

84. 3/30/2024 84 Objectives of Functional Point Analysis: (CO3) Encourage Approximation:  FPA helps in the estimation of the work, time and materials needed to develop a software project. Organizations are able to plan and manage projects more accurately when a common measure of functionality is available. To assist with project management:  Project managers can monitor and manage software development projects with the help of FPA. Managers are able to evaluate productivity, monitor progress, and make well-informed decisions about resource allocation and project timeframes by measuring the software’s functional points. Comparative analysis:  By enabling benchmarking, it gives businesses the ability to assess how their software projects measure up to industry standards or best practices in terms of size and complexity. This can be useful for determining where improvements might be made and for evaluating how well development procedures are working.

85. 3/30/2024 85 Objectives of Functional Point Analysis: (CO3) Improve Your Cost-Benefit Analysis: It offers a foundation for assessing the value provided by the program in respect to its size and complexity, which helps with cost-benefit analysis. Making educated judgements about project investments and resource allocations can benefit from having access to this information. Comply with Business Objectives: It assists in coordinating software development activities with an organization’s business objectives. It guarantees that software development efforts are directed towards providing value to end users by concentrating on user-oriented functionality.

86. 3/30/2024 86 Types of FP Attributes Inputs : information entering the system Outputs : information leaving the system Enquiries : requests for instant access to information Internal logical files : information held within the system External interface files : information held by other system that is used by the system being analyzed.

87. 3/30/2024 87 Types of Functional Point Analysis: Transactional Functional Type External Input (EI):  EI processes data or control information that comes from outside the application’s boundary. The EI is an elementary process. External Output (EO):  EO is an elementary process that generates data or control information sent outside the application’s boundary.  External Inquiries (EQ):  EQ is an elementary process made up of an input-output combination that results in data retrieval. 

88. 3/30/2024 88 Data Functional Type Data Functional Type Internal Logical File (ILF): A user-identifiable group of logically related data or control information maintained within the boundary of the application. External Interface File (EIF): A group of users recognizable logically related data allusion to the software but maintained within the boundary of another software.

89. 3/30/2024 89 Types of FP Attributes

90. 3/30/2024 90 Benefits of Functional Point Analysis: Technological Independence:  It calculates a software system’s functional size independent of the underlying technology or programming language used to implement it. As a result, it is a technology-neutral metric that makes it easier to compare projects created with various technologies. Better Accurate Project Estimation:  It helps to improve project estimation accuracy by measuring user interactions and functional needs. Project managers can improve planning and budgeting by using the results of the FPA to estimate the time, effort and resources required for development. Improved Interaction:  It provides a common language for business analysts, developers, and project managers to communicate with one another and with other stakeholders. By communicating the size and complexity of software in a way that both technical and non-technical audiences can easily understand this helps close the communication gap.

91. 3/30/2024 91 Benefits of Functional Point Analysis: Making Well-Informed Decisions:  FPA assists in making well-informed decisions at every stage of the software development life cycle. Based on the functional requirements, organizations can use the results of the FPA to make decisions about resource allocation, project prioritization, and technology selection. Early Recognition of Changes in Scope : Early detection of changes in project scope is made easier with the help of FPA. Better scope change management is made possible by the measurement of functional requirements, which makes it possible to evaluate additions or changes for their effect on the project’s overall size.

92. 3/30/2024 92 Benefits of Functional Point Analysis: Measurement Parameters Examples Number of External Inputs (EI) Input screen and tables Number of External Output (EO) Output screens and reports Number of external inquiries (EQ) Prompts and interrupts Number of internal files (ILF) Databases and directories Number of external interfaces (EIF) Shared databases and shared routines

93. 3/30/2024 93 Weights of 5 Functional Point Attributes: Measurement Parameter Low Average High Number of external inputs (EI) 3 4 6 Number of external outputs (EO) 4 5 7 Number of external inquiries (EQ) 3 4 6 Number of internal files (ILF) 7 10 15 Number of External Interfaces (EIF) 5 7 10

94. 3/30/2024 94 Weights of 5 Functional Point Attributes: Measurement Parameter Count Weighing Factor Total_Count Simple Average Complex Number of external inputs (EI) 32 32*4=128 3 4 6 Number of external outputs (EO) 60 60*5=300 4 5 7 Number of external inquiries (EQ) 24 24*4=96 3 4 6 Number of internal files (ILF) 8 8*10=80 7 10 15 Number of external interfaces (EIF) 2 2*7=14 5 7 10 Algorithms used Count total → 618

95. 3/30/2024 95 Weights of 5 Functional Point Attributes: From the above tables, Functional Point is calculated with the following formula FP = Count-Total * [0.65 + 0.01 * ⅀(fi)] = Count * CAF

96. Typical Characteristic weights  3/30/2024 96

97. 3/30/2024 97 Weights of 5 Functional Point Attributes: CAF = [0.65 + 0.01 * ⅀ (fi) ] ⅀ (fi) =  sum of all 14 questions and it also shows the complexity factor – CAF. CAF varies from 0.65 to 1.35 and ⅀ (fi)  ranges from 0 to 70. When ⅀ (fi)  = 0, CAF = 0.65 and when ⅀ (fi)  = 70, CAF = 0.65 + (0.01*70) = 0.65 + 0.7 = 1.35   ∑(f i )  is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-CAF (where i ranges from 1 to 14).

98. Weights of 5 Functional Point Attributes: 0 <= ∑(f i ) <=70 and CAF ranges from 0.65 to 1.35 because When  ∑(f i )  = 0 then CAF = 0.65 When  ∑(f i )  = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35 Degree of Influence (DI) for each of these 14 General System Characteristics GSCs is assessed on a scale of 0 to 5. (b) If a particular General System Characteristics GSC has no influence, then its weight is taken as 0 and if it has a strong influence then its weight is 5. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI). Then Value Adjustment Factor (VAF) is computed from TDI by using the formula:  VAF = (TDI * 0.01) + 0.65 3/30/2024 98

99. 3/30/2024 99 Function Point Calculation The first step is to calculate Unadjusted Function Point (UFP) UFP=(Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 + (Number of files)*10 + (Number of interfaces)*7 Functional Units Weighting factors Low Average High Inputs (EI) 3 4 6 Output (EO) 4 5 7 Inquiries (EQ) 3 4 6 Logical files (ILF) 7 10 15 Interface files (EIF) 5 7 10

100. 3/30/2024 100 Function Point Calculation FP = Count-total * [0.65 + 0.01 * ∑(f i )] FP   = Count-total * CAF where Count-total is obtained from the above Table. Count – Total = UFP                CAF = [0.65 + 0.01 *∑(f i )] and  ∑(f i )  is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-CAF (where i ranges from 1 to 14). Usually, a student is provided with the value of ∑(f i ) Also note that  ∑(f i )  ranges from 0 to 70, i.e.,               0 <= ∑(f i ) <=70 and CAF ranges from 0.65 to 1.35 because When  ∑(f i )  = 0 then CAF = 0.65 When  ∑(f i )  = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35

101. 3/30/2024 101 14 GENERAL SYSTEM CHARACTERISTICS (GSC) 1. Does the system require reliable backup and recovery ? 2. Is data communication required ? 3. Are there distributed processing functions ? 4. Is performance critical ? 5. Will the system run in an existing heavily utilized operational environment ? 6. Does the system require on line data entry ? 7. Does the on line data entry require the input transaction to be built over multiple screens or operations ? 8. Are the master files updated on line ? 9. Is the inputs, outputs, files, or inquiries complex ? 10. Is the internal processing complex ? 11. Is the code designed to be reusable ? 12. Are conversion and installation included in the design ? 13. Is the system designed for multiple installations in different organizations ? 14. Is the application designed to facilitate change and ease of use by the user

102. 3/30/2024 102 EXAMPLE Consider a project with the following functional units: Number of user inputs = 50 Number of user outputs = 40 Number of user enquiries = 35 Number of user files = 06 Number of external interfaces = 04 Assume all complexity adjustment factors and weighting factors are average. Compute the function points for the project. Value of ∑(f i )] is 42.

103. 3/30/2024 103 Solution FP   = Count-total * CAF FP = Count-total * [0.65 + 0.01 * ∑(f i )] Count – Total = UFP      CAF = [0.65 + 0.01 *∑(f i )] Count-total / UFP = 50 x 4 + 40 x 5 + 35 x 4 + 6 x 10 + 4 x 7 = 200 + 200 + 140 + 60 + 28 = 628 CAF = 0.65 + 0.01 * ∑(f i )] = 0.65 + 0.01 * 42 = 0.65 + 0.42 = 1.07 FP = Count-total * CAF = 628 x 1.07 = 672

104. Understand the concept of control flow graph Cyclomatic complexity 3/30/2024 104 Objectives

105. 3/30/2024 105 Control F low Graph (CFG) (CO3 ) A control flow graph describes the sequence in which the different instructions of a program get executed. In other words, a control flow graph describes how the control flows through the program. Control Flow Graph is a visual representation of a program’s control flow, showing how the program progresses through various statements and decision points. A Control Flow Graph (CFG) is the graphical representation of control flow or computation during the execution of programs or applications. Control flow graphs are mostly used in static analysis as well as compiler applications, as they can accurately represent the flow inside a program unit. The control flow graph was originally developed by Frances E. Allen..

106. 3/30/2024 106 Characteristics of Control Flow Graph Control flow graph is process oriented. Control flow graph shows all the paths that can be traversed during a program execution. Control flow graph is a directed graph. Edges in CFG portray control flow paths and the nodes in CFG portray basic blocks.

107. 3/30/2024 107 How to draw Control Flow Graph In order to draw the control flow graph of a program, all the statements of a program must be numbered first. The different numbered statements serve as nodes of the control flow graph. An edge from one node to another node exists if the execution of the statement representing the first node can result in the transfer of control to the other node.

108. 3/30/2024 108 Notation of Control Flow Testing Control flow testing consists of four nodes, namely, Node Edge Decision Node Junction node

109. 3/30/2024 109 How to draw Control Flow Graph 1. If-else

110. 3/30/2024 110 How to draw Control Flow Graph 2.  While

111. 3/30/2024 111 How to draw Control Flow Graph 3.  do-while

112. 3/30/2024 112 How to draw Control Flow Graph 3.  for

113. 3/30/2024 113 How to draw Control Flow Graph Example if A = 10 then if B > C A = B else A = C endif endif print A, B, C

114. 3/30/2024 114 How to draw Control Flow Graph Flowchart of above example will be:

115. 3/30/2024 115 How to draw Control Flow Graph Control Flow Graph of above example will be:

116. 3/30/2024 116 Sequence, Selection and Iteration in CFG The CFG for any program can be easily drawn by knowing how to represent the sequence, selection, and iteration type of statements in the CFG.

117. 3/30/2024 117 Sequence, Selection and Iteration in CFG

118. 3/30/2024 118 Sequence, Selection and Iteration in CFG

119. 3/30/2024 119 Sequence, Selection and Iteration in CFG

120. 3/30/2024 120 Sequence, Selection and Iteration in CFG

121. 3/30/2024 121 Sequence, Selection and Iteration in CFG

122. 3/30/2024 122 Sequence, Selection and Iteration in CFG

123. 3/30/2024 123 Cyclomatic Complexity (CO3) There are three different ways to compute the cyclomatic complexity. Method 1: Given a control flow graph G of a program, the cyclomatic complexity V(G) can be computed as: V(G) = E – N + 2 where N is the number of nodes of the control flow graph and E is the number of edges in the control flow graph. For the CFG of example shown in above example, E=7 and N=6. Therefore, the cyclomatic complexity = 7-6+2 = 3.

124. 3/30/2024 124 Cyclomatic Complexity (contd..) Method 2: An alternative way of computing the cyclomatic complexity of a program from an inspection of its control flow graph is as follows: V(G) = Total number of bounded areas + 1 In the program’s control flow graph G, any region enclosed by nodes and edges can be called as a bounded area.

125. 3/30/2024 125 Cyclomatic Complexity (contd..) Method 3: The cyclomatic complexity of a program can also be easily computed by computing the number of decision statements of the program. If N is the number of decision statement of a program, then the McCabe’s metric is equal to N+1.

126. 3/30/2024 126 Thank You