CS 451 Software Engineering Winter 2009

1. Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu CS 451Software EngineeringWinter 2009

2. Design within the Context of Software Engineering

3. Software Design • Between Requirement and Coding • Including: • Data Design • Architectural Design • Interface Design • Component Design • Detailed Design • Need to be modeled, analyzed, and reviewed in industrial strength software.

4. Translating the Analysis Model into the Design Model Component Design Interface Design Architecture Design Data/Class Design

5. Design Process and Desgin Quality

6. Design Engineering • Software design is an iterative process through which requirements are translated into a “blueprint” for constructing software • Abstraction • Refinement

7. Design Engineering • A design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer. • A design must be a readable, understandable guide for those who generate code and those who test and subsequently support the software. • The design should provide a complete picture of the software, addressing, the data, functional, and behavioral domains from an implementation perspective.

8. Design Quality • FURPS – Functionality, Usability, Reliability, Performance, and Supportability. • Functionality – assessed by evaluating: • the feature set • capabilities of the program. • Usability - assessed by considering: • human factors, • overall aesthetics, • consistency, • end-user documentation.

9. Design Quality - Functionality, Usability, Reliability, Performance, and Supportability • Reliability – is evaluated by measuring: • the frequency and severity of failure, • the accuracy, of output results, • the mean-time-to-failure, • the ability to recover from failure, • the predictability of the program. • Performance – is measured by: • processing speed, • response time, • resource consumption, • throughput, • efficiency

10. Design Quality - Functionality, Usability, Reliability, Performance, and Supportability • Supportability – combines: • the ability to extend the program (extensibility), • adaptability, • serviceability • testability, • compatibility, • configurability.

11. Design Concepts

12. Design Concepts • Abstraction • Architecture • Patterns • Data • Modularity • Information Hiding • Functional Independence • Refinement • Refactoring • Design Classes

13. Design Concepts-Abstraction • “Abstraction is one of the fundamental ways that we as humans cope with complexity.” Grady Booch • “What kinds of things do we abstract? • data • objects • procedures • modules • just about anything

14. Design Concepts-Architecture • Software architecture alludes to “the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. • Architecture is: • the structure or organization of program components (modules), • the manner in which these components interact, • the structure of data that are used by the components.

15. Design Concepts-Patterns • “A pattern is a named nugget of insight which conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns.” • “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” Christopher Alexander

16. Design Concepts -Modularity • MODULARITY • “Modularity is the single attribute of software that allows a program to be intellectually manageable” • Software is divided into separately named and addressable components, sometimes called modules, that are integrated to satisfy problem requirements.

17. Design Concepts –Information Hiding • Modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information. • This means that inadvertent errors introduced during modification are less likely to propagate to other locations within the software. • Changes to the internal representation of one module should have not have an effect on other modules.

18. Design Concepts-Functional Independence • Functional independence is achieved by developing modules with “single-minded” function and an “aversion” to excessive interaction with other modules. • We want to design software so that each module addresses a specific subfunction of requirements and has a simple interface when viewed from other parts of the program structure.

19. Design Concepts-Functional Independence • Independence is assessed by using two qualitative criteria: • Cohesion – How related a module is to itself. It should perform a single task and require little interaction with the rest of the program. • Coupling is an indication of the interconnectoin among modules in a software structure.

20. Design Concepts-Refinement • Stepwise refinement is when a program is developed by successively refining levels of procedural detail. • Refinement is actually the process of elaboration.

21. Design Concepts-Refactoring • Refactoring is a reorganizational technique that simplifies the design )of code) of a component without changing its function or behavior.

22. Design Concepts-Design Classes • Refine analysis classes by providing design details • Create a new set of design classes that implement a software infrastructure to support the business solution • Five types: • User interface classes • Business domain classes • Process classes • Persistent classes • System classes