1. Software Design: The Next Step A presentation by Sean Matthews

2. Kruchen, P. 2005. "Editor's Introduction: Software Design in a Postmodern Era." Software, IEEE 22 (2): 16-18. Kruchten, P. 2005. "Casting software design in the function-behavior-structure framework." Software, IEEE 22 (2): 52-58.

3. Intro We’ve reached a plateau in software design We’ve reached a plateau in software design What are the next directions? What are the next directions? Where are we? Where are we? Where do we go from here? Where do we go from here?

4. Where are we? “…we can systematically harvest and organize our collective knowledge, experience, and wisdom– variously captured in design principles and heuristics, patterns, best practices, and bad smells– into a coherent whole.” “…we can systematically harvest and organize our collective knowledge, experience, and wisdom– variously captured in design principles and heuristics, patterns, best practices, and bad smells– into a coherent whole.”

5. Where do we go from here? We need to… We need to… Bridge the gap between user needs and the way we express requirements Bridge the gap between user needs and the way we express requirements Improve design analysis, validation, and verification techniques Improve design analysis, validation, and verification techniques Bridge the gap between design and code that programmers create manually Bridge the gap between design and code that programmers create manually

6. Requirements Engineering Design Coding

7. Where do we go from here? Expand the boundaries of software design to fill in the gaps Expand the boundaries of software design to fill in the gaps “When we program and test, we’re making decisions about the system under construction: this is doing design.” “When we program and test, we’re making decisions about the system under construction: this is doing design.” Design activities should be included in other parts of the software development process Design activities should be included in other parts of the software development process

8. Analogous situations To demonstrate how and why design should be combined with other phases of the SD process, the author casts it in a general, recently formulated engineering framework. To demonstrate how and why design should be combined with other phases of the SD process, the author casts it in a general, recently formulated engineering framework.

9. Functional-Behavior-Structure A development framework applicable to any engineering discipline A development framework applicable to any engineering discipline John Gero, design scientist John Gero, design scientist 8 processes link a set of five elements that lead us from a set of abstract functions to a design description 8 processes link a set of five elements that lead us from a set of abstract functions to a design description

10. Functional-Behavior-Structure FBS Elements FBS Elements F: functions F: functions Be: expected behaviors Be: expected behaviors Bs: behaviors (actual) Bs: behaviors (actual) S: synthesis S: synthesis D: documentation D: documentation

11. Functional-Behavior-Structure FBS Processes FBS Processes Formulation (F  Be) Formulation (F  Be) Synthesis (Be  S) Synthesis (Be  S) Analysis (S  Bs) Analysis (S  Bs) Evaluation (Be  Bs) Evaluation (Be  Bs) Documentation (S  D) Documentation (S  D) Structural reformulation (S  S) Structural reformulation (S  S) Behavioral reformulation (S  Be) Behavioral reformulation (S  Be) Functional reformulation (S  F) Functional reformulation (S  F)

12. FBS Framework

13. Applying FBS to SE “…design is making choices that will shape the final product.” “…design is making choices that will shape the final product.” Requirements, coding, and testing activities all involve some design Requirements, coding, and testing activities all involve some design Traditionally, design means “building a model of the system to be constructed up to the point at which coding can begin.” Traditionally, design means “building a model of the system to be constructed up to the point at which coding can begin.”

14. Applying FBS to SE

16. SE lessons from FBS Lack of fundamental theory Lack of fundamental theory Physics has its laws Physics has its laws Evaluation process is experimental Evaluation process is experimental Concrete S, almost no addition to D Concrete S, almost no addition to D

17. SE lessons from FBS Legacy systems Legacy systems D  S  Be  F D  S  Be  F Reuse Reuse F  Be  S F  Be  S “catalogue look-up” “catalogue look-up”

18. SE lessons from FBS Modeling Modeling …to automate the coding and deployment artifacts …to automate the coding and deployment artifacts …to describe a system’s expected behavior (Be), and thereby facilitate the synthesis (S) process …to describe a system’s expected behavior (Be), and thereby facilitate the synthesis (S) process

19. SE lessons from FBS Design patterns Design patterns If F 1 and Bs 1 = F 2 and Bs 2, then the designs are analogous If F 1 and Bs 1 = F 2 and Bs 2, then the designs are analogous We can communicate design fragments and share and reuse practical solutions for recurrent problems. We can communicate design fragments and share and reuse practical solutions for recurrent problems.

20. The BIG picture In software production, programming is primarily a design activity In software production, programming is primarily a design activity In software manufacturing it is not In software manufacturing it is not Decisions about structure and the way something is done Decisions about structure and the way something is done Also, testing to a smaller extent Also, testing to a smaller extent Assessment of test results determine whether design needs reworking Assessment of test results determine whether design needs reworking

21. Conclusions Generally, something gets lost between design and implementation. Generally, something gets lost between design and implementation. With FBS, design becomes part of coding and implementation. With FBS, design becomes part of coding and implementation. SE needs to find approaches to describing software that easily translate to static analysis and code generation. SE needs to find approaches to describing software that easily translate to static analysis and code generation.

22. Kruchen, P. 2005. "Editor's Introduction: Software Design in a Postmodern Era." Software, IEEE 22 (2): 16-18. Kruchten, P. 2005. "Casting software design in the function-behavior-structure framework." Software, IEEE 22 (2): 52-58. References