1. Introduction to Design

2. What is Design? 2 minutes Pairs

3. Definition of Design May refer to an activity: “When I design, I always use a whiteboard first”

4. Definition of Design May refer to an activity: “When I design, I always use a whiteboard first” May refer to a product: “My design is super cool, I know it will work”

5. Definition of Design May refer to an activity: “When I design, I always use a whiteboard first” May refer to a product: “My design is super cool, I know it will work” May refer to a field: “Software design is complex”

6. Definition of Design Webster’s 3 rd : –Sketch a pattern or outline for a problem –To plan and carry out in a skillful way

7. Definition of Design Webster’s 3 rd : –Sketch a pattern or outline for a problem –To plan and carry out in a skillful way SE: –the process of identifying a set of components and interfaces from a set of requirements relying on SE techniques, imagination, experience and art!

8. Design is not unique to SE There are countless design fields –Architecture design –Graphic design –Fashion design –Game design –Chip design –Car design –Instrument design –Product design –… But also –Law –Chemical synthesis –Process design –Study design –… And also –Writing –Painting –Sculpturing –Music composition –…

9. What is the Purpose of Design in SE? 1 minute Pairs

10. What is the Purpose of Design in SE? To determine a set of components and interfaces that satisfy a set of requirements To manage complexity To solve in the abstract before we invest in solving in the concrete

11. Need a shared language Design quality is in part subjective However, we need a language that we can use to –understand the underlying implications of certain designs –understand the intentions of designers –effectively frame our communication about designs

12. Purpose of Design Is a road map Describes a path from requirements to the outcome Describes what the implementers should do Is a guide towards future change

13. Purpose of Design: More Shared understanding Is a road map –understandable, unambiguous, consistent, helpful, … Describes a path from requirements to the outcome –correct, complete, concise, verifiable, effective, … Describes what the implementers should do –elegant, partitionable, recomposable, resilient, … Is a guide towards future change –evolvable, …

14. Objectives for Overall Process Apply rigor Separate concerns Anticipate change Generalize Work incrementally

15. Design Concerns Different concerns must be addressed by a design solution Relative importance of concerns depends on problem being solved –“I want my e-commerce site to have a recognizable logo” –“My e-commerce site must scale to 1 million hits per minute”

16. Design Concerns Different concerns must be addressed by a design solution Relative importance of concerns depends on problem being solved –“I want my e-commerce site to have a recognizable logo” –“My e-commerce site must scale to 1 million hits per minute” Importance of a given concern might not be obvious –“I want my payroll software to properly handle the exchange rate”

17. Design Concerns Different concerns must be addressed by a design solution Relative importance of concerns depends on problem being solved –“I want my e-commerce site to have a recognizable logo” –“My e-commerce site must scale to 1 million hits per minute” Importance of a given concern might not be obvious –“I want my payroll software to properly handle the exchange rate” As a designer, you need to find the concerns that are most important and have most impact

18. Some designs are better than others What makes a given software design “good”? What makes a given software design “beautiful”? What should we strive for in creating a software design? (4 minutes, pairs)

19. Design Principles Structure to accommodate change

20. Design Principles Structure to accommodate change We don’t know what the future needs are Implementers need to be able to change code quickly How do we achieve this?

21. Abstraction What is it? Why is it useful? How can you tell abstract from concrete?

22. Levels of Abstraction Abstract and concrete are relative –More than two levels (such as “hot” and “cold”) –“A” is more abstract (concrete) than “B” Top-down or bottom-up design An approach to dealing with complexity

23. Objectives for Class Design High Cohesion Low Coupling Completeness Convenience Clarity Consistency Fault Prevention and Tolerance

24. Cohesion What is it?

25. Cohesion Definition: The degree to which all elements of a component are directed towards a single task and all elements directed towards that task are contained in a single component. Refers to the contents of a single component.

26. Coupling What is it?

27. Coupling Definition: the amount of interaction among components in a system. High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the component is connected.

28. Emphasis on Changability Change abounds… –During design –During coding –Upon delivery –After use Reuse for later projects

29. Changability: Basic Principles Low Coupling: Reducing interdependency –Changes don’t propagate –Reuse is facilitated High Cohesion: Grouping functionality –Easier to find things –Metaphor guides decisions Encapsulation

30. Keep It Simple Nothing should be more complicated than absolutely essential The inherent complexity of everything should be questioned: can it be done more simply?

31. Encapsulation Hide design decisions that are most likely to change, thereby protecting other parts of the program from change if the design decision is changed

32. Modularity Modular software is divided into separately named and addressable components that are integrated to satisfy requirements Why do this?

33. Modularity Modular software is divided into separately named and addressable components that are integrated to satisfy requirements. Reduces complexity (compared to monolithic programs). –Fewer control paths –Smaller span of reference –Fewer variables Tradeoff: need to integrate modules

34. Criteria for Defining Modular System Composability: components can be used in system Understandability: Module can be understood as stand-alone unit Coupling: Small changes to the system requirements result in changes to individual modules Isolation: Effects of aberrant condition is constrained within a module

35. Maintainability What reasons are there for having to maintain a system?

36. Maintainability Most maintenance tasks are designed to enhance the software. 60% of total costs! 1. corrective maintenance: removal of residual errors, present in the product when delivered or during maintenance (+20%) 2. adaptive maintenance: adjusting application to changes in environment (+20%) 3. perfective maintenance: improving some of the software features or qualities (+50%)

37. Design Levels Architecture Interface Code design (Detailed design) Executable design

38. Design Levels Architecture Interface Code design (Detailed design) Executable design These are not necessarily disjoint

39. Design Levels Architecture –Associate capabilities in requirements with components that implement them. –Components are modules. –Architecture abstractly describes interconnection of components Interface Code design (Detailed design) Executable design

40. Design Levels Architecture Interface –Describes in detail how components communicate Code design (Detailed design) Executable design

41. Design Levels Architecture Interface Code design (Detailed design) –Algorithms and data structures. –Data representations. –Primitive implementation-level constructs. Executable design

42. Design Levels Architecture Interface Code design (Detailed design) Executable design –Memory allocation –Data formats

43. Conceptual Design Documents the concept of the system (such as done for the SRS) Describes form of system Used to communicate with client Provides sources of data, report and screen layout, user interface Independent of implementation

44. Technical Design Provides low-level details of system Used to communicate with developers Describes components, hierarchies of functions, data structures and data flows

45. Design Patterns A design pattern names, abstracts, and identifies the key aspects of a common design structure that can make it useful for creating a reusable design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities.

46. Redesign (refactoring) When a design does not allow easy modification, change the design Refactoring: modifying the code to improve the design without changing the functionality If maintaining the software is difficult, refactor first

47. Advice Every design approach separates system into components Component should have well-defined inputs and outputs Each system activity should be accomplished by one (and only one) component