3. TOPICS TO BE COVERED :  Abstraction  Architecture  Aspects  Cohesion  Data Design  Design Process  Functional independence  Good design  Information Hiding  Modularity  Object Oriented Design  Pattern  Quality Attributes  Quality Guidelines  Refactoring  Separation of concern  Software design  Stepwise Refinements

4. DESIGN CONCEPTS? DESIGN CONCEPTS? “Idea behind design” “Idea behind design”

5. SOME QUICK QUESTIONS: Design? Design? What is it? What is it? Who does it? Who does it? Why is it important? Why is it important? What is design in software engineering? What is design in software engineering?

6. Quick answers ! “A PLAN OR DRAWING”. “A PLAN OR DRAWING”. According to Dr. Mitch Kapur in DOBBS Journal “It’s where you stand with a foot in two worlds—the world of technology and the world of people and human purposes—and you try to bring the two together”. Design is the place where software quality is established. According to Dr. Mitch Kapur in DOBBS Journal “It’s where you stand with a foot in two worlds—the world of technology and the world of people and human purposes—and you try to bring the two together”. Design is the place where software quality is established. Software engineers. Software engineers. Design allows you to model the system or product that is to be built. 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 Software design is the process of implementing software solutions to one or more sets of problems

7. TRANSLATING THE ANALYSIS MODEL INTO THE DESIGN MODEL TRANSLATING THE ANALYSIS MODEL INTO THE DESIGN MODEL

8. DESIGN PROCESS: Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software 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 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

9. QUALITY ATTRIBUTES OF A GOOD DESIGN : QUALITY ATTRIBUTES OF A GOOD DESIGN: Good software design should exhibit: Firmness: A program should not have any bugs that inhibit its function. 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 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 Delight: The experience of using the program should be pleasurable one

10. QUALITY GUIDELINES A design should be modular; that is, the software should be logically partitioned into elements or subsystems. 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 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 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 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 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 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. A design should be represented using a notation that effectively communicates its meaning.

11. FUNDAMENTAL DESIGN CONCEPTS: FUNDAMENTAL DESIGN CONCEPTS:  Abstraction  Architecture  Patterns  Separation of concerns  Modularity  Information hiding  Functional independence  Refinement  Aspects Refactoring Refactoring  Object-oriented Design concepts  Design classes

12. Permits one to concentrate on a problem at some level of abstraction without regard to low level detail Abstraction :

13. Architecture : Overall structure of the system

14. Patterns : General reusable solution which can be used again and again.

15. Separation of concerns: Any complex problem can be more easily handled if it is sub-divided into pieces.

16. Modularity : Single attribute of software that allows a program to be intellectually manageable.

17. MODULARITY AND SOFTWARE COST

18. Information Hiding: The way of hiding the unnecessary details

19. Functional Independence: Achieved by developing modules with “single minded” function and low coupling. It can be measured using two criteria: -Cohesion -Coupling

20. A process of elaboration of details of abstraction. A process of elaboration of details of abstraction. Stepwise refinement is a top-down design strategy. Stepwise refinement is a top-down design strategy. Abstraction and refinement are complementary concepts. Abstraction and refinement are complementary concepts. Refinement:

21. An aspect is a representation of a cross-cutting concern. An aspect is a representation of a cross-cutting concern. Consider two requirements, A and B. Requirement A crosscuts requirement B “if a software refinement has been chosen in which B cannot be satisfied without taking A into account. Consider two requirements, A and B. Requirement A crosscuts requirement B “if a software refinement has been chosen in which B cannot be satisfied without taking A into account. Aspects:

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

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

24. The requirements model defines a set of analysis classes 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. 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 Characteristics of Design Classes Design Classes:

25. DESIGN CLASS FOR FLOORPLAN AND COMPOSITE AGGREGATION FOR THE CLASS

26. DIMENSIONS OF THE DESIGN MODEL

27. DESIGN MODEL ELEMENTS: Data Design Elements Data Design Elements Architectural Design Elements Architectural Design Elements Interface Design Elements Interface Design Elements Component-Level Design Elements Component-Level Design Elements Deployment-Level Design Elements Deployment-Level Design Elements

28. Data-model  Data structures Data-model  Data structures Data-model  Database architecture Data-model  Database architecture 1.Data Design Elements

29. The architectural model [sha96] is derived from three sources: Information about the application domain for the software to be built 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 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 The availability of architectural patterns and styles 2.Architectural Design Elements

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

31. INTERFACE REPRESENTATION FOR CONTROL PANEL

32. The component-level design for software fully describes the internal detail of each software component 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 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 4.Component-level Design Elements

33. 5.DEPLOYMENT-LEVEL DESIGN ELEMENTS Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software Deployment-level design elements indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software

34. A UML COMPONENT DIAGRAM

35. A UML deployment diagram

36. Nahi Nahi… Nahi Nahi… Any Question ?