SOFTWARE DESIGN ENGINEERING UNIT-3 PPT.pptx

Ff

1. SOFTWARE DESIGN ENGINEERING UNIT-3

2. SRS SDD

3. Software Design Software design is a mechanism to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. It deals with representing the client's requirement, as described in SRS (Software Requirement Specification) document, into a form, i.e., easily implementable using programming language. The software design phase is the first step in SDLC (Software Design Life Cycle), which moves the concentration from the problem domain to the solution domain. In software design, we consider the system to be a set of components or modules with clearly defined behaviors & boundaries.

4.           Correctness :Software design should be correct as per requirement. Completeness :The design should have all components like data structures, modules, and external interfaces, etc. Efficiency: Resources should be used efficiently by the program. Flexibility: Able to modify on changing needs. Consistency: There should not be any inconsistency in the design. Maintainability:  The design should be so simple so that it can be easily maintainable by other designers .

5. DESIGN CONCEPTS A set of fundamental software design concepts has evolved over the history of software engineering. Each provides the software designer with a foundation from which more sophisticated design methods can be applied. Each helps you answer the following questions: • What criteria can be used to partition software into individual components? • How is function or data structure detail separated from a conceptual representation of the software? • What uniform criteria define the technical quality of a software design?

6. Abstraction Abstraction is the act of representing essential features without including the background details or explanations. the abstraction is used to reduce complexity and allow efficient design and implementation of complex software systems. Many levels of abstraction can be posed. At the highest level of abstraction, a solution is stated in broad terms using the language of the problem environment. At lower levels of abstraction, a more detailed description of the solution is provided. As different levels of abstraction are developed, you work to create both procedural and data abstractions. A procedural abstraction refers to a sequence of instructions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed. A data abstraction is a named collection of data that describes a data object. Architecture

7. Modularity : Modularity is the most common manifestation of separation of concerns. Software is divided into separately named and addressable components, sometimes called module. Modularity is the single attribute of software that allows a program to be intellectually manageable.

8. Information Hiding The principle of information hiding suggests that modules be “characterized by design decisions that hides from all others.” In other words, 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. The use of information hiding as a design criterion for modular systems provides the greatest benefits when modifications are required during testing and later during software maintenance. Because most data and procedural detail are hidden from other parts of the software, inadvertent errors introduced during modification are less likely to propagate to other locations within the software

9. Functional Independence: The concept of functional independence is a direct out growth of separation of concerns, modularity, and the concepts of abstraction and information hiding. Functional independence is achieved by developing modules with “single minded” function and an “aversion” to excessive interaction with other modules. Independence is assessed using two qualitative criteria: cohesion and coupling. Cohesion is an indication of the relative functional strength.

10. Cohesion is a natural extension of the information-hiding concept. A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should do just one thing. Although you should always strive for high cohesion (i.e., single-mindedness). Coupling is an indication of interconnection among modules in a software structure. Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface. In software design, you should strive for the lowest possible coupling.

11. Refinement Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth. Refinement is actually a process of elaboration. You begin with a statement of function that is defined at a high level of abstraction. Abstraction and refinement are complementary concepts. Abstraction enables you to specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details. Refinement helps you to reveal low-level details as design progresses

12. Software Design Principles: Software design principles are concerned with providing means to handle the complexity of the design process effectively. Effectively managing the complexity will not only reduce the effort needed for design but can also reduce the scope of introducing errors during design.   .

13. . Problem Partitioning: For small problem, we can handle the entire problem at once but for the significant problem, divide the problems and conquer the problem it means to divide the problem into smaller pieces so that each piece can be captured separately.

14. . Problem Partitioning: For software design, the goal is to divide the problem into manageable pieces. Benefits of Problem Partitioning Software is easy to understand Software becomes simple Software is easy to test Software is easy to modify Software is easy to maintain Software is easy to expand These pieces cannot be entirely independent of each other as they together form the system. They have to cooperate and communicate to solve the problem. This communication adds complexity.

15. . Abstraction: An abstraction is a tool that enables a designer to consider a component at an abstract level without bothering about the internal details of the implementation. Abstraction can be used for existing element as well as the component being designed. Here, there are two common abstraction mechanisms Functional Abstraction Data Abstraction Functional Abstraction

16. . Functional Abstraction The details of the algorithm to accomplish the functions are not visible to the user of the function. Functional abstraction forms the basis for Function oriented design approaches. Data Abstraction Details of the data elements are not visible to the users of data. Data Abstraction forms the basis for Object Oriented design approaches

17. . Modularity: Modularity specifies to the division of software into separate modules which are differently named and addressed and are integrated later on in to obtain the completely functional software. It is the only property that allows a program to be intellectually manageable. Single large programs are difficult to understand and read due to a large number of reference variables, control paths, global variables, etc. Each module is a well-defined system that can be used with other applications. Each module has single specified objectives. Modules can be separately compiled and saved in the library. Modules should be easier to use than to build. Modules are simpler from outside than inside.

18. . Advantages of Modularity There are several advantages of Modularity It allows large programs to be written by several or different people It encourages the creation of commonly used routines to be placed in the library and used by other programs. It simplifies the overlay procedure of loading a large program into main storage. It provides more checkpoints to measure progress. It provides a framework for complete testing, more accessible to test It produced the well designed and more readable program. Disadvantages of Modularity There are several disadvantages of Modularity Execution time maybe, but not certainly, longer Storage size perhaps, but is not certainly, increased Compilation and loading time may be longer Inter-module communication problems may be increased More linkage required, run-time may be longer, more source lines must be written, and more documentation has to be done

19. . Modular Design Modular design reduces the design complexity and results in easier and faster implementation by allowing parallel development of various parts of a system. We discuss a different section of modular design in detail in this section: Functional Independence:  Functional independence is achieved by developing functions that perform only one kind of task and do not excessively interact with other modules. Independence is important because it makes implementation more accessible and faster. The independent modules are easier to maintain, test, and reduce error propagation and can be reused in other programs as well. Thus, functional independence is a good design feature which ensures software quality.

20. . It is measured using two criteria: Cohesion: It measures the relative function strength of a module. Coupling: It measures the relative interdependence among modules. 2. Information hiding: The fundamental of Information hiding suggests that modules can be characterized by the design decisions that protect from the others, i.e., In other words, modules should be specified that data include within a module is inaccessible to other modules that do not need for such information.

21. . What is Coupling and Cohesion? Coupling refers to the degree of interdependence between software modules. High coupling means that modules are closely connected and changes in one module may affect other modules. Low coupling means that modules are independent, and changes in one module have little impact on other modules. coupling and cohesion are important factors in determining the maintainability, scalability, and reliability of a software system. High coupling and low cohesion can make a system difficult to change and test, while low coupling and high cohesion make a system easier to maintain and improve.

22. . Following are the types of Coupling: Data Coupling:  If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. In data coupling, the components are independent of each other and communicate through data. Module communications don’t contain tramp data. Example-customer billing system. Stamp Coupling  In stamp coupling, the complete data structure is passed from one module to another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice was made by the insightful designer, not a lazy programmer. Control Coupling : If the modules communicate by passing control information, then they are said to be control coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring and reuse of functionality. Example- sort function that takes comparison function as an argument

23. . External Coupling:  In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. Ex- protocol, external file, device format, etc. Common Coupling : The modules have shared data such as global data structures. The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data accesses, and reduced maintainability. Content Coupling : In a content coupling, one module can modify the data of another module, or control flow is passed from one module to the other module. This is the worst form of coupling and should be avoided.

24. . Temporal Coupling:  Temporal coupling occurs when two modules depend on the timing or order of events, such as one module needing to execute before another. This type of coupling can result in design issues and difficulties in testing and maintenance. Sequential Coupling:  Sequential coupling occurs when the output of one module is used as the input of another module, creating a chain or sequence of dependencies. This type of coupling can be difficult to maintain and modify. Communicational Coupling: Communicational coupling occurs when two or more modules share a common communication mechanism, such as a shared message queue or database. This type of coupling can lead to performance issues and difficulty in debugging. Functional Coupling:  Functional coupling occurs when two modules depend on each other’s functionality, such as one module calling a function from another module. This type of coupling can result in tightly-coupled code that is difficult to modify and maintain .

25. . Following are the types of Cohesion: 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. Sequential Cohesion:  An element outputs some data that becomes the input for other element, i.e., data flow between the parts. It occurs naturally in functional programming languages. Communicational Cohesion:  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:  Elements of procedural cohesion ensure the order of execution. Actions are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA.

26. . Temporal Cohesion:  The elements are related by their timing involved. A module connected with temporal cohesion all the tasks must be executed in the same time span. This cohesion contains the code for initializing all the parts of the system. Lots of different activities occur, all at unit time. Logical Cohesion:  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:  The elements are not related(unrelated). 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. Procedural Cohesion:  This type of cohesion occurs when elements or tasks are grouped together in a module based on their sequence of execution, such as a module that performs a set of related procedures in a specific order. Procedural cohesion can be found in structured programming languages.

27. . Communicational Cohesion:  Communicational cohesion occurs when elements or tasks are grouped together in a module based on their interactions with each other, such as a module that handles all interactions with a specific external system or module. This type of cohesion can be found in object-oriented programming languages. Temporal Cohesion:  Temporal cohesion occurs when elements or tasks are grouped together in a module based on their timing or frequency of execution, such as a module that handles all periodic or scheduled tasks in a system. Temporal cohesion is commonly used in real-time and embedded systems. Informational Cohesion:  Informational cohesion occurs when elements or tasks are grouped together in a module based on their relationship to a specific data structure or object, such as a module that operates on a specific data type or object. Informational cohesion is commonly used in object-oriented programming. Functional Cohesion:  This type of cohesion occurs when all elements or tasks in a module contribute to a single well-defined function or purpose, and there is little or no coupling between the elements. Functional cohesion is considered the most desirable type of cohesion as it leads to more maintainable and reusable code.

28. . it’s good for software to have low coupling and high cohesion. Low coupling means the different parts of the software don’t rely too much on each other, which makes it safer to make changes without causing unexpected problems. High cohesion means each part of the software has a clear purpose and sticks to it, making the code easier to work with and reuse. Following these principles helps make software stronger, more adaptable, and easier to grow.

29. . Strategy of Design: A good system design strategy is to organize the program modules in such a method that are easy to develop and latter too, change. Structured design methods help developers to deal with the size and complexity of programs. Analysts generate instructions for the developers about how code should be composed and how pieces of code should fit together to form a program. To design a system, there are two possible approaches: Top-down Approach Bottom-up Approach

30. . 1. Top-down Approach:  This approach starts with the identification of the main components and then decomposing them into their more detailed sub-components.

31. . 2. Bottom-up Approach:  A bottom-up approach begins with the lower details and moves towards up the hierarchy, as shown in fig. This approach is suitable in case of an existing system.

32. . Design modeling: represents the features of the software that helps engineer to develop it effectively, the architecture, the user interface, and the component level detail. Design modeling provides a variety of different views of the system like architecture plan for home or building. Different methods like data-driven, pattern-driven, or object-oriented methods are used for constructing the design model. All these methods use set of design principles for designing a model.

33. . Data design:  It represents the data objects and their interrelationship in an entity-relationship diagram. Entity-relationship consists of information required for each entity or data objects as well as it shows the relationship between these objects. It shows the structure of the data in terms of the tables. It shows three type of relationship – One to one, one to many, and many to many. In one to one relation, one entity is connected to another entity. In one many relation, one Entity is connected to more than one entity. un many to many relations one entity is connected to more than one entity as well as other entity also connected with first entity using more than one entity

34. . Architectural design:  It defines the relationship between major structural elements of the software. It is about decomposing the system into interacting components. It is expressed as a block diagram defining an overview of the system structure – features of the components and how these components communicate with each other to share data. It defines the structure and properties of the component that are involved in the system and also the inter-relationship among these components.

35. . User Interfaces design:  It represents how software communicates with users, focusing on the behavior and interaction of the system. The user interface (UI) refers to the space where users engage with the controls or displays of a product. UI design is implemented in a variety of industries, such as military applications, vehicles, aircraft, audio equipment, and computer peripherals.

36. . Component level design:   It transforms the structural elements of the software architecture into a procedural description of software components. It is a perfect way to share a large amount of data. Components need not be concerned with how data is managed at a centralized level i.e. components need not worry about issues like backup and security of the data.