SlideShare a Scribd company logo
1 of 9
Lecture 11

 A complex system that works is invariably found to have
evolved from a simple system that worked. To manage the
complexity of the system we need to apply the principles of
separation of concern, modularity, and abstraction. This leads
to designs that are easy to understand and hence easy to
maintain.
 Separation of concern allows us to deal with different
individual aspects of a problem by considering these aspects in
isolation and independent of each other.
 A complex system may be divided into smaller pieces of lesser
complexity called modules. This is the classic divide-and-
conquer philosophy.
Managing Complexity of a
Software System

Software Design
 Once the requirements of a software system have
been established, we proceed to design that system.
During the design phase, the focus shifts from what
to how. That is, at this stage we try to answer the
question of how to build the system.
 The design activity provides a roadmap to
progressively transform the requirements through a
number on stages into the final product by
describing the structure of the system to be
implemented.

 Software design is not a sequential process. Design of a
software system evolves through a number of iterations. The
design process usually involves developing a number of
different models, looking at the system from different angles
and describing the system at various levels of abstraction.
 A activities performed at this stage include design of the
software architecture by showing the division of system into
sub-systems or modules, the specification of the services
provided by these sub-systems and their interfaces with each
other, division of each sub-system into smaller components and
services and interfaces provided by each one of these
components.
Software Design Process

 Software design process revolves around
decomposing of the system into smaller and simpler
units and then systematically integrates these units
to achieve the desired results. Two fundamental
strategies have been used to that end. These are
 functional or structured design and
 object oriented design.
Software Design Strategies

 Functional or Structured Design
 The structure of the system revolves around functions. The
entire system is abstracted as a function that provides the
desired functionality. The structure of the system revolves
around functions. The entire system is abstracted as a
function that provides the desired functionality.
 Object-oriented Design
 In this case the system is decomposed into a set of objects
that cooperate and coordinate with each other to implement
the desired functionality. In this case the system state is
decentralized and each object is held responsible for
maintaining its own state.
Software Design Strategies

 A software design can be looked at from different angles
and different parameters can be used to measure and
analyze its quality. These parameters include efficiency,
compactness, reusability, and maintainability. A good
design from one angle may not seem to be suitable when
looked from a different perspective.
 For example, if we need to design an embedded system
for the control of a nuclear reactor or a cruise missile, we
would probably require a system that is very efficient and
maintainability would be of secondary concern.
Software Design Qualities

 Maintenance contributes towards a major share of
the overall software cost, the objective of the design
activity, in most cases, is to produce a system that is
easy to maintain. A maintainable design is the one in
which cost of system change is minimal and is
flexible enough so that it can be easily adapted to
modify exiting functionality and add new
functionality.
Maintainable Design

 Coupling is a measure of independence of a module or
component. Loose coupling means that different system
components have loose or less reliance upon each other.
Hence, changes in one component would have a limited
affect on other components.
 Strong cohesion implies that all parts of a component
should have a close logical relationship with each other.
That means, in the case some kind of change is required
in the software, all the related pieces are found at one
place. Hence, once again, the scope is limited to that
component itself.
Coupling and Cohesion

More Related Content

Viewers also liked

Lecture 02
Lecture 02Lecture 02
Lecture 02Rana Ali
 
Lecture 15
Lecture 15Lecture 15
Lecture 15Rana Ali
 
Lecture 07
Lecture 07Lecture 07
Lecture 07Rana Ali
 
Lecture 01
Lecture 01Lecture 01
Lecture 01Rana Ali
 
Lecture 09
Lecture 09Lecture 09
Lecture 09Rana Ali
 
Lecture 08
Lecture 08Lecture 08
Lecture 08Rana Ali
 
Lecture 12
Lecture 12Lecture 12
Lecture 12Rana Ali
 
Lecture 03
Lecture 03Lecture 03
Lecture 03Rana Ali
 
Lecture 05
Lecture 05Lecture 05
Lecture 05Rana Ali
 
Lecture 06
Lecture 06Lecture 06
Lecture 06Rana Ali
 
Lecture 04
Lecture 04Lecture 04
Lecture 04Rana Ali
 
Lecture 13
Lecture 13Lecture 13
Lecture 13Rana Ali
 
Lecture 10
Lecture 10Lecture 10
Lecture 10Rana Ali
 
Lecture 14
Lecture 14Lecture 14
Lecture 14Rana Ali
 
Software Engineering - Lecture 02
Software Engineering - Lecture 02Software Engineering - Lecture 02
Software Engineering - Lecture 02Asifuzzaman Hridoy
 
Software engineering lecture notes
Software engineering   lecture notesSoftware engineering   lecture notes
Software engineering lecture notesAmmar Shafiq
 
CSC426 - Software Engineering Lecture Note
CSC426   - Software Engineering Lecture NoteCSC426   - Software Engineering Lecture Note
CSC426 - Software Engineering Lecture NoteBro Shola Ajayi
 
Software engineering lecture notes
Software engineering lecture notesSoftware engineering lecture notes
Software engineering lecture notesSiva Ayyakutti
 

Viewers also liked (19)

Lecture 02
Lecture 02Lecture 02
Lecture 02
 
Lecture 15
Lecture 15Lecture 15
Lecture 15
 
Lecture 07
Lecture 07Lecture 07
Lecture 07
 
Lecture 01
Lecture 01Lecture 01
Lecture 01
 
Lecture 09
Lecture 09Lecture 09
Lecture 09
 
Lecture 08
Lecture 08Lecture 08
Lecture 08
 
Lecture 12
Lecture 12Lecture 12
Lecture 12
 
Lecture 03
Lecture 03Lecture 03
Lecture 03
 
Lecture 05
Lecture 05Lecture 05
Lecture 05
 
Nlp
NlpNlp
Nlp
 
Lecture 06
Lecture 06Lecture 06
Lecture 06
 
Lecture 04
Lecture 04Lecture 04
Lecture 04
 
Lecture 13
Lecture 13Lecture 13
Lecture 13
 
Lecture 10
Lecture 10Lecture 10
Lecture 10
 
Lecture 14
Lecture 14Lecture 14
Lecture 14
 
Software Engineering - Lecture 02
Software Engineering - Lecture 02Software Engineering - Lecture 02
Software Engineering - Lecture 02
 
Software engineering lecture notes
Software engineering   lecture notesSoftware engineering   lecture notes
Software engineering lecture notes
 
CSC426 - Software Engineering Lecture Note
CSC426   - Software Engineering Lecture NoteCSC426   - Software Engineering Lecture Note
CSC426 - Software Engineering Lecture Note
 
Software engineering lecture notes
Software engineering lecture notesSoftware engineering lecture notes
Software engineering lecture notes
 

Similar to Lecture 11

SWE-401 - 7. Software Design Strategies
SWE-401 - 7. Software Design StrategiesSWE-401 - 7. Software Design Strategies
SWE-401 - 7. Software Design Strategiesghayour abbas
 
Software Design and Modularity
Software Design and ModularitySoftware Design and Modularity
Software Design and ModularityDanyal Ahmad
 
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptxchapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptxMahmoudZidan53
 
Software Design ppt.pptx
Software Design ppt.pptxSoftware Design ppt.pptx
Software Design ppt.pptxSeemaSarvath1
 
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfUNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfputtipavan23022023
 
Software Design abtic.pptx
Software Design abtic.pptxSoftware Design abtic.pptx
Software Design abtic.pptxssuser8c0d24
 
Function oriented design
Function oriented designFunction oriented design
Function oriented designVidhun T
 
SWE-401 - 5. Software Design Basics
SWE-401 - 5. Software Design BasicsSWE-401 - 5. Software Design Basics
SWE-401 - 5. Software Design Basicsghayour abbas
 
07 software design
07   software design07   software design
07 software designkebsterz
 
07 software design
07   software design07   software design
07 software designkebsterz
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software EngineeringVarsha Ajith
 
Function Oriented and Object Oriented Design,Modularization techniques
Function Oriented and Object Oriented Design,Modularization techniquesFunction Oriented and Object Oriented Design,Modularization techniques
Function Oriented and Object Oriented Design,Modularization techniquesnimmik4u
 
The Role of the Architect in ERP and PDM System Deployment
The Role of the Architect in ERP and PDM System DeploymentThe Role of the Architect in ERP and PDM System Deployment
The Role of the Architect in ERP and PDM System DeploymentGlen Alleman
 
Design patterns for self adaptive systems
Design patterns for self adaptive systemsDesign patterns for self adaptive systems
Design patterns for self adaptive systemsijseajournal
 

Similar to Lecture 11 (20)

SWE-401 - 7. Software Design Strategies
SWE-401 - 7. Software Design StrategiesSWE-401 - 7. Software Design Strategies
SWE-401 - 7. Software Design Strategies
 
Software Design and Modularity
Software Design and ModularitySoftware Design and Modularity
Software Design and Modularity
 
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptxchapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
chapter-6-Software_Engineering_P1_MohamedElhawy_19135002.pptx
 
Software Design ppt.pptx
Software Design ppt.pptxSoftware Design ppt.pptx
Software Design ppt.pptx
 
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvfUNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
UNIT3 PART2.pptx dhfdifhdsfvgudf dhfbdhbffdvf
 
Unit 1
Unit 1Unit 1
Unit 1
 
Unit 3
Unit 3Unit 3
Unit 3
 
Software Design abtic.pptx
Software Design abtic.pptxSoftware Design abtic.pptx
Software Design abtic.pptx
 
Function oriented design
Function oriented designFunction oriented design
Function oriented design
 
SWE-401 - 5. Software Design Basics
SWE-401 - 5. Software Design BasicsSWE-401 - 5. Software Design Basics
SWE-401 - 5. Software Design Basics
 
Sda 2
Sda   2Sda   2
Sda 2
 
Full Paper
Full PaperFull Paper
Full Paper
 
07 software design
07   software design07   software design
07 software design
 
07 software design
07   software design07   software design
07 software design
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software Engineering
 
Function Oriented and Object Oriented Design,Modularization techniques
Function Oriented and Object Oriented Design,Modularization techniquesFunction Oriented and Object Oriented Design,Modularization techniques
Function Oriented and Object Oriented Design,Modularization techniques
 
The Role of the Architect in ERP and PDM System Deployment
The Role of the Architect in ERP and PDM System DeploymentThe Role of the Architect in ERP and PDM System Deployment
The Role of the Architect in ERP and PDM System Deployment
 
Design patterns for self adaptive systems
Design patterns for self adaptive systemsDesign patterns for self adaptive systems
Design patterns for self adaptive systems
 
Ch6.ppt
Ch6.pptCh6.ppt
Ch6.ppt
 
114 425-433
114 425-433114 425-433
114 425-433
 

Lecture 11

  • 2.   A complex system that works is invariably found to have evolved from a simple system that worked. To manage the complexity of the system we need to apply the principles of separation of concern, modularity, and abstraction. This leads to designs that are easy to understand and hence easy to maintain.  Separation of concern allows us to deal with different individual aspects of a problem by considering these aspects in isolation and independent of each other.  A complex system may be divided into smaller pieces of lesser complexity called modules. This is the classic divide-and- conquer philosophy. Managing Complexity of a Software System
  • 3.  Software Design  Once the requirements of a software system have been established, we proceed to design that system. During the design phase, the focus shifts from what to how. That is, at this stage we try to answer the question of how to build the system.  The design activity provides a roadmap to progressively transform the requirements through a number on stages into the final product by describing the structure of the system to be implemented.
  • 4.   Software design is not a sequential process. Design of a software system evolves through a number of iterations. The design process usually involves developing a number of different models, looking at the system from different angles and describing the system at various levels of abstraction.  A activities performed at this stage include design of the software architecture by showing the division of system into sub-systems or modules, the specification of the services provided by these sub-systems and their interfaces with each other, division of each sub-system into smaller components and services and interfaces provided by each one of these components. Software Design Process
  • 5.   Software design process revolves around decomposing of the system into smaller and simpler units and then systematically integrates these units to achieve the desired results. Two fundamental strategies have been used to that end. These are  functional or structured design and  object oriented design. Software Design Strategies
  • 6.   Functional or Structured Design  The structure of the system revolves around functions. The entire system is abstracted as a function that provides the desired functionality. The structure of the system revolves around functions. The entire system is abstracted as a function that provides the desired functionality.  Object-oriented Design  In this case the system is decomposed into a set of objects that cooperate and coordinate with each other to implement the desired functionality. In this case the system state is decentralized and each object is held responsible for maintaining its own state. Software Design Strategies
  • 7.   A software design can be looked at from different angles and different parameters can be used to measure and analyze its quality. These parameters include efficiency, compactness, reusability, and maintainability. A good design from one angle may not seem to be suitable when looked from a different perspective.  For example, if we need to design an embedded system for the control of a nuclear reactor or a cruise missile, we would probably require a system that is very efficient and maintainability would be of secondary concern. Software Design Qualities
  • 8.   Maintenance contributes towards a major share of the overall software cost, the objective of the design activity, in most cases, is to produce a system that is easy to maintain. A maintainable design is the one in which cost of system change is minimal and is flexible enough so that it can be easily adapted to modify exiting functionality and add new functionality. Maintainable Design
  • 9.   Coupling is a measure of independence of a module or component. Loose coupling means that different system components have loose or less reliance upon each other. Hence, changes in one component would have a limited affect on other components.  Strong cohesion implies that all parts of a component should have a close logical relationship with each other. That means, in the case some kind of change is required in the software, all the related pieces are found at one place. Hence, once again, the scope is limited to that component itself. Coupling and Cohesion