CS 451 Software Engineering Winter 2009 Yuanfang Cai Room 104, - - PowerPoint PPT Presentation

Drexel University

CS 451 Software Engineering Winter 2009

1

Yuanfang Cai Room 104, University Crossings 215.895.0298 yfcai@cs.drexel.edu

Drexel University

Design within the Context of Software Engineering

2

Drexel University

Software Design

 Between Requirement and Coding  Including:

 Data Design  Architectural Design  Interface Design  Component Design

 Need to be modeled, analyzed, and reviewed in

industrial strength software.

3

Drexel University

Translating the Analysis Model into the Design Model

4

Data/ Class Design Architecture Design Interface Design Component Design

Drexel University

Design Process and Desgin Quality

5

Drexel University

Design Engineering

 Software design is an iterative process through

which requirements are translated into a “blueprint” for constructing software

 Abstraction  Refinement

6

Drexel University

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.

7

Drexel University

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.

8

Drexel University

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

9

Drexel University

Design Quality - Functionality, Usability, Reliability, Performance, and Supportability

 Supportability – combines:

 the ability to extend the program (extensibility),  adaptability,  testability,  compatibility,  configurability.

10

Drexel University

Design Concepts

11

Drexel University

Design Concepts

 Abstraction  Architecture  Patterns  Modularity  Information Hiding  Functional Independence  Refinement  Refactoring

12

Drexel University

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

13

Drexel University

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.

14

Drexel University

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

15

Drexel University

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.

16

Drexel University

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.

17

Drexel University

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.

18

Drexel University

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.

19

Drexel University

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.

20

Drexel University

Design Concepts-Refactoring

 Refactoring is a reorganizational technique that

simplifies the design )of code) of a component without changing its function or behavior.

21

Drexel University

SOLID

Drexel University

Single Responsibility Principle

 There can be only one reason for a class to

change.

Drexel University

Open-Close Principle

 Classes and methods should be open for

extension but closed for modification.

Drexel University

Liskov Substitution Principle

 Every function or method which expects an

• bject parameter of class A must be able to

accept a subclass of A as well, without knowing it.

Drexel University

Interface Segregation Principle

 Classes should not depend on interfaces that

they not use.

Drexel University

Dependency Inversion Principle

 High level classes should not depend on low

level classes. Both should depend upon

• abstractions. Details should depend upon
• abstractions. Abstractions should not depend

upon details.

Drexel University

Please refer to the design document rubric

28