his is another platform hosting several free presentations. You can find PPTs detailing the functions of a "Hotel Management System," including check-in/check-out processes, guest information

Technology stack: List the technologies used to build the system, such as HTML, CSS, PHP, MySQL, or Python.
Implementation: Explain the development methodology and how different parts of the system are implemented and integrated.
Advantages: Discuss the benefits of your system, such as efficiency, accuracy, and improved guest experience.
Conclusion: Summarize your project's achievements and future scope, including potential improvements.
AI responses may include mistakes. Learn more

1. Software Design Presented By:- Dr. Riya Gohil LDRP-ITR

2. Design? What is it? Who does it? Why is it important? What is design in software engineering? 2

3. Answers !!! 3 “A PLAN OR DRAWING”. Software Design -- An iterative process transforming requirements into a “blueprint” for constructing the software Design allows you to model the system or product that is to be built. Software design is the process of implementing software solutions to one or more sets of problems

4. 4

5. Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software During the design process the software requirements model is transformed into design models that describe the details of the data structures, system architecture, interface, and components. Design is considered to be high level of abstraction. 5

6. Good software design should exhibit: Firmness: A program should not have any bugs that inhibit its function. Commodity: A program should be suitable for the purposes for which it was intended Delight: The experience of using the program should be pleasurable one 6

7. A design should be modular ; that is, the software should be logically partitioned into elements or subsystems. A design should contain distinct representations of data, architecture, interfaces, and components A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns. A design should lead to components that exhibit independent functional characteristics. A design should lead to interfaces that reduce the complexity of connections between components and with the external environment. A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. A design should be represented using a notation that effectively communicates its meaning. 7

8. Abstraction Architecture Patterns Modularity Information hiding Functional independence Refinement Refactoring Design classes 8

9. Abstraction 9

10. 10 Abstraction allows designers to focus on solving a problem without being concerned about irrelevant lower level details. There are two types of abstraction available : Procedural abstraction – a sequence of instructions that have a specific and limited function. Eg: Word OPEN for a door. Data abstraction – a named collection of data that describes a data object. Data abstraction for door would be a set of attributes that describes the door (e.g. door type, swing direction, weight, dimension). Control abstraction – a program control mechanism without specifying internal detail. It is used to coordinate all activities in operating system

11. 11

12. 12 The overall structure of the software and the ways in which the structure provides conceptual integrity for a system : Consists of components, connectors, and the relationship between them. Some of the Architecture models are described below, Structural models – architecture as organized collection of components Framework models – attempt to identify repeatable architectural patterns Dynamic models – indicate how program structure changes as a function of external events Process models – focus on the design of the business or technical process that system must accommodate Functional models – used to represent system functional hierarchy

13. 13 General reusable solution which can be used again and again.

14. 14 Software engineer can use the design pattern during the entire software design process. Each pattern is to provide an insight to a designer who can determine the following-: Whether the pattern can be reused. Whether the pattern is applicable to the current project. Whether the pattern can be used to develop a similar but functionally or structurally different design pattern.

15. 15 Types of Design Patterns Architectural patterns : These patterns are high-level strategies that refer to the overall structure and organization of a software system. That is, they define the elements of a software system such as subsystems, components, classes, etc. Design patterns: These patterns are medium-level strategies that are used to solve design problems. They provide a means for the refinement of the elements of a software system or the relationship among components or mechanisms that affect component-to-component. Idioms: These patterns are low-level patterns, which are programming-language specific. They describe the implementation of a software component, the method used for interaction among software components.

16. Single attribute of software that allows a program to be intellectually manageable. What is the "right" number of modules for a specific software design…??? 16

17. Software is divided into separately named and addressable components, often called modules, that are integrated to satisfy problem requirements. This leads to a " divide and conquer " conclusion—it's easier to solve a complex problem when you break it into manageable pieces. It has been stated that "modularity is the single attribute of software that allows a program to be intellectually manageable“. 17

18. - Modular decomposability: A design method provides a systematic mechanism for decomposing the problem into sub-problems -->reduce the complexity and achieve the modularity Modular composability: A design method enables existing design components to be assembled into a new system. Modular understandability: A module can be understood as a standalone unit it will be easier to build and easier to change. Modular continuity: A small changes to the system requirements result in changes to individual modules, rather than system- wide changes. Modular protection: An aberrant condition occurs within a module and its effects are constrained within the module. 18

19. 19

20. 20 The way of hiding the unnecessary details

21. 21 Information (data and procedure) contained within a module should be inaccessible to other modules that have no need for such information. Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure used by the module Modules should be specified and designed so that information (procedure and data) contained within a module is inaccessible to other modules that have no need for such information. Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function. This enforces access constraints to both procedural (i.e., implementation) detail and local data structures .

22. module controlled interface "secret" algorithm data structure details of external interface resource allocation policy clients a specific design decision

23. Functional Independence 23 Achieved by developing modules with “single minded” function and low coupling.

24. 24 Functional independence is achieved by developing a module to perform given set of functions without interacting with other parts of the system. It can be measured using two criteria: -Cohesion -Coupling Design modules based on independent functional features

25. Cohesion : A natural extension of the information hiding concept a module may perform a number of tasks. A cohesive module performs a single task in a procedure with little interactions with others. Types of cohesion: Functional cohesion Sequential cohesion Communication cohesion Procedural cohesion Element /Task ✔ Temporal cohesion ✔ Logical cohesion ✔ Coincidental cohesion Module 25

26. Cohesion : A natural extension of the information hiding concept a module may perform a number of tasks. A cohesive module performs a single task in a procedure with little interactions with others. Types of cohesion: Functional cohesion Sequential cohesion Communication cohesion Procedural cohesion A B C ✔ Temporal cohesion ✔ Logical cohesion ✔ Coincidental cohesion Module 26

27. Cohesion : A natural extension of the information hiding concept a module may perform a number of tasks. A cohesive module performs a single task in a procedure with little interactions with others. Types of cohesion: Functional cohesion Sequential cohesion Communication cohesion Procedural cohesion A B C ✔ Temporal cohesion ✔ Logical cohesion ✔ Coincidental cohesion Same data shared by elements Module 27

28. Cohesion : A natural extension of the information hiding concept a module may perform a number of tasks. A cohesive module performs a single task in a procedure with little interactions with others. Types of cohesion: Functional cohesion Sequential cohesion Communication cohesion Procedural cohesion A B C ✔ Temporal cohesion ✔ Logical cohesion ✔ Coincidental cohesion Module 28

29. Cohesion : A natural extension of the information hiding concept a module may perform a number of tasks. A cohesive module performs a single task in a procedure with little interactions with others. Types of cohesion: Functional cohesion Sequential cohesion Communication cohesion Procedural cohesion A B C ✔ Temporal cohesion ✔ Logical cohesion ✔ Coincidental cohesion Same time Module 29

30. Cohesion : A natural extension of the information hiding concept a module may perform a number of tasks. A cohesive module performs a single task in a procedure with little interactions with others. Types of cohesion: Functional cohesion Sequential cohesion Communication cohesion Procedural cohesion A B C ✔ Temporal cohesion ✔ Logical cohesion ✔ Coincidental cohesion Similar Activities Module 30

31. Cohesion : A natural extension of the information hiding concept a module may perform a number of tasks. A cohesive module performs a single task in a procedure with little interactions with others. Types of cohesion: Functional cohesion Sequential cohesion Communication cohesion Procedural cohesion Temporal cohesion Logical cohesion Coincidental cohesion A Module B C 32

32. 32 Coupling: A measure of interconnection/interdependence among modules in a program structure. Coupling depends on the interface complexity between modules. Types of coupling: No direct coupling Data coupling Stamp coupling Control coupling Common coupling content coupling : independent of each other. : passing parameter or data interaction : data structure id passed via argument list : share related control logical (control flag) : sharing common data areas. : module A use of data or control information maintained in another module.

33. Stepwise refinement is a top-down design strategy 33

34. Refinement is actually a process of elaboration. It begin with a statement of function (or description of information) that is defined at a high level of abstraction and reach at the lower level of abstraction. Terminates when all instructions are expressed in terms of any underlying computer or programming language. Abstraction and refinement are complementary concepts 34

35. restructuring (rearranging) code… “changing the structure of a program so that the functionality is not changed” 35

36. 36 Refactoring is a reorganization technique that simplifies the design (or internal code structure) of a component without changing its function or external behaviour. It removes redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failures.

37. “ Design system using self-contained objects and object classes” Objects are abstractions of real world or system entities and manage themselves Objects are independent and encapsulate state and represent information System functionality is expressed in terms of object services Shared data are eliminated. Objects communicate by message passing 37

38. The requirements model defines a set of analysis classes Set of design classes that refine the analysis classes by providing design detail that will enable the classes to be implemented, and implement a software infrastructure that supports the business solution. Characteristics of Design Classes 38 Design Classes

39. 39

40. 40

41. Data Design Elements Architectural Design Elements Interface Design Elements Component-Level Design Elements Deployment-Level Design Elements 41

42. Data-model 🡪 Data structures Data-model 🡪 Database architecture 42 1.Data Design Elements

43. The architectural model [sha96] is derived from three sources: Information about the application domain for the software to be built Specific requirements model elements such as data flow diagrams of analysis classes, their relationship and collaborations for the problems at hand The availability of architectural patterns and styles 43

44. There are three important elements of interface design: User interface (UI) External interfaces to other systems, devices, networks, or other producers or consumers of information Internal interfaces between various design components 44

45. 45

46. The component-level design for software fully describes the internal detail of each software component The component-level design defines data structures for all local data objects and algorithmic detail for all processing that occurs within a component and an interface that allows access to all component operations 46

47.  Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software 47

48. 48

49. 49

50. A data flow diagram (DFD) maps out the flow of information for any process or system. It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs, outputs, storage points and the routes between each destination.  Data flowcharts can range from simple, even hand-drawn process overviews, to in-depth, multi-level DFDs that dig progressively deeper into how the data is handled. They can be used to analyze an existing system or model a new one. Like all the best diagrams and charts, a DFD can often visually “say” things that would be hard to explain in words, and they work for both technical and nontechnical audiences, from developer to CEO. That’s why DFDs remain so popular after all these years. While they work well for data flow software and systems, they are less applicable nowadays to visualizing interactive, real-time or database-oriented software or systems. What is a data flow diagram?

51. Symbols and Notations Used in DFDs

52. Each process should have at least one input and an output. Each data store should have at least one data flow in and one data flow out. Data stored in a system must go through a process. All processes in a DFD go to another process or a data store. DFD rules and tips

53. It is also known as a context diagram. It’s designed to be an abstraction view, showing the system as a single process with its relationship to external entities. It represents the entire system as a single bubble with input and output data indicated by incoming/outgoing arrows.  0-level DFD: 

54. In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes. In this level, we highlight the main functions of the system and breakdown the high-level process of 0-level DFD into subprocesses.  1-level DFD: 

55. 2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to plan or record the specific/necessary detail about the system’s functioning.  2-level DFD: 

56. Student Attendance Management System Data Flow Diagram

57. Data flow diagram(DFD) for Online shopping website

58. Online food system

59. Thank you