lecture 18 design concepts (3)

20
Introduction to Software Engineering Muhammad Nasir Design Concepts (3) [email protected]

Upload: sakhawat-jameel-tanoli

Post on 15-Jul-2015

101 views

Category:

Software


2 download

TRANSCRIPT

Page 1: Lecture 18   design concepts (3)

Introduction to Software Engineering

Muhammad Nasir

Design Concepts (3)

[email protected]

Page 2: Lecture 18   design concepts (3)

Agenda

Design Concepts Design Pattern Separation of Concern Modularity Information Hiding Functional Independence Aspects Refactoring OO Design Concepts

Page 3: Lecture 18   design concepts (3)

Design Pattern

“Software Design Pattern is a solution to a recurring design problem.”

Design patterns have four essential elements: Pattern Name Problem Solution Consequences

Page 4: Lecture 18   design concepts (3)

Separation of Concerns

Any complex problem can be more easily handled if it is subdivided into pieces

A concern is a feature or behavior that is specified as part of the requirements model for the software!

Concern Separation makes a problem more manageable i.e. Less effort and time to solve.!

Page 5: Lecture 18   design concepts (3)

Separation of Concerns

Separation of concerns is manifested in other related design concepts: modularity, aspects, functional independence, and refinement.

Page 6: Lecture 18   design concepts (3)

Modularity

Modularity is the most common manifestation of separation of concerns.

Software is divided into separately named and addressable components

Sometimes called modules, that are integrated to satisfy problem requirements.

Page 7: Lecture 18   design concepts (3)

Modularity

Monolithic software (i.e., a large program composed of a single module) cannot be easily grasped by a software engineer.

Modularity leads to “divide and conquer” strategy. – it is easier to solve a complex problem when you break into a manageable pieces.

Page 8: Lecture 18   design concepts (3)

Modularity

Refer figure that state that effort (cost) to develop an individual software module does decrease if total number of modules increase.

However as the no. of modules grows, the effort (cost) associated with integrating the modules also grows.

Page 9: Lecture 18   design concepts (3)

Modularity vs. Software Cost

Page 10: Lecture 18   design concepts (3)

Modularity vs. Software Cost

Page 11: Lecture 18   design concepts (3)

Information Hiding

Modules should be specified and designed so that information (algorithm and data) contained within a module is in-accessible to other modules that have no need for such information.

The intent of information hiding is to hide the details of data structure and procedural processing behind a module interface.

Page 12: Lecture 18   design concepts (3)

Information Hiding

Page 13: Lecture 18   design concepts (3)

Information Hiding

It gives benefits when modifications are required during testing and maintenance because data and procedure are hiding from other parts of software, un-intentional errors introduced during modification are less.

Page 14: Lecture 18   design concepts (3)

Why Information Hiding

Page 15: Lecture 18   design concepts (3)

Functional Independence

Page 16: Lecture 18   design concepts (3)

Aspects

Page 17: Lecture 18   design concepts (3)

Aspects – Example

Page 18: Lecture 18   design concepts (3)

Refactoring

Page 19: Lecture 18   design concepts (3)

OO – Design Concepts

Page 20: Lecture 18   design concepts (3)

The End

Thanks for listening Questions would be appreciated.