SlideShare a Scribd company logo
Software Engineering Software Design Slide 1
Software Engineering
Software Design
Software Engineering Software Design Slide 2
Software Design
Deriving a solution which
satisfies software requirements
Software Engineering Software Design Slide 3
Stages of Design
• Problem understanding
– Look at the problem from different angles to discover the
design requirements.
• Identify one or more solutions
– Evaluate possible solutions and choose the most appropriate
depending on the designer's experience and available resources.
• Describe solution abstractions
– Use graphical, formal or other descriptive notations to
describe the components of the design.
• Repeat process for each identified abstraction
until the design is expressed in primitive terms.
Software Engineering Software Design Slide 4
The Design Process
• Any design may be modelled as a directed graph
made up of entities with attributes which participate
in relationships.
• The system should be described at several different
levels of abstraction.
• Design takes place in overlapping stages. It is
artificial to separate it into distinct phases but
some separation is usually necessary.
Software Engineering Software Design Slide 5
Phases in the Design Process
Ar
chitectur
al
design
Abstr
act
specifica
tio
n
Interface
design
Component
design
Da
ta
structur
e
design
Algorithm
design
System
architectur
e
Softw
are
specifica
tion
Interface
specifica
tion
Component
specifica
tion
Da
ta
structur
e
specifica
tion
Algorithm
specifica
tion
Requir
ements
specifica
tion
Design acti
vities
Design pr
oducts
Software Engineering Software Design Slide 6
Design Phases
• Architectural design: Identify sub-systems.
• Abstract specification: Specify sub-systems.
• Interface design: Describe sub-system interfaces.
• Component design: Decompose sub-systems
into components.
• Data structure design: Design data structures to hold
problem data.
• Algorithm design: Design algorithms for problem
functions.
Software Engineering Software Design Slide 7
Design
• Computer systems are not monolithic: they are usually
composed of multiple, interacting modules.
• Modularity has long been seen as a key to cheap, high
quality software.
• The goal of system design is to decode:
– What the modules are;
– What the modules should be;
– How the modules interact with one-another
Software Engineering Software Design Slide 8
Modular programming
• In the early days, modular programming was
taken to mean constructing programs out of
small pieces: “subroutines”
• But modularity cannot bring benefits unless the
modules are
– autonomous,
– coherent and
– robust
Software Engineering Software Design Slide 9
Procedural Abstraction
• The most obvious design methods involve
functional decomposition.
• This leads to programs in which procedures
represent distinct logical functions in a program.
• Examples of such functions:
– “Display menu”
– “Get user option”
• This is called procedural abstraction
Software Engineering Software Design Slide 10
Programs as Functions
• Another view is programs as functions:
input output
x  f  f (x)
the program is viewed as a function from a set I of legal
inputs to a set O of outputs.
• There are programming languages (ML, Miranda, LISP)
that directly support this view of programming
Well-suited to certain
application domains
- e.g., compilers
Less well-suited to distributed, non-
terminating systems
- e.g., process control systems, operating
systems like WinNT, ATM machines
Software Engineering Software Design Slide 11
Object-oriented design
– The system is viewed as a collection of
interacting objects.
– The system state is decentralized and each
object manages its own state.
– Objects may be instances of an object class
and communicate by exchanging methods.
Software Engineering Software Design Slide 12
Five Criteria for Design Methods
• We can identify five criteria to help evaluate
modular design methods:
– Modular decomposability;
– Modular composability;
– Modular understandability;
– Modular continuity;
– Modular protection.
Software Engineering Software Design Slide 13
Modular Decomposability
• This criterion is met by a design method if the
method supports the decomposition of a problem
into smaller sub-problems, which can be solved
independently.
• In general method will be repetitive: sub-
problems will be divided still further
• Top-down design methods fulfil this criterion;
stepwise refinement is an example of such method
Software Engineering Software Design Slide 14
Hierarchical Design Structure
System level
Sub-system
level
Software Engineering Software Design Slide 15
Top-down Design
• In principle, top-down design involves starting
at the uppermost components in the hierarchy
and working down the hierarchy level by level.
• In practice, large systems design is never
truly top-down. Some branches are designed
before others. Designers reuse experience (and
sometimes components) during the design
process.
Software Engineering Software Design Slide 16
Modular Composability
• A method satisfies this criterion if it leads to the production
of modules that may be freely combined to produce new
systems.
• Composability is directly related to the issue of reusability
• Note that composability is often at odds with
decomposability; top-down design,
– for example, tends to produce modules that may not be composed
in the way desired
• This is because top-down design leads to modules which
fulfil a specific function, rather than a general one
Software Engineering Software Design Slide 17
Examples
• The Numerical Algorithm Group (NAG)
libraries contain a wide range of routines for
solving problems in linear algebra, differential
equations, etc.
• The Unix shell provides a facility called a pipe,
written “”, whereby
– the standard output of one program may be
redirected to the standard input of another; this
convention favours composability.
Software Engineering Software Design Slide 18
Modular Understandability
• A design method satisfies this criterion if it
encourages the development of modules which
are easily understandable.
• COUNTER EXAMPLE 1. Take a thousand lines program,
containing no procedures; it’s just a long list of sequential
statements. Divide it into twenty blocks, each fifty statements
long; make each block a method.
• COUNTER EXAMPLE 2. “Go to” statements.
Software Engineering Software Design Slide 19
Understandability
• Related to several component characteristics
– Can the component be understood on its own?
– Are meaningful names used?
– Is the design well-documented?
– Are complex algorithms used?
• Informally, high complexity means many
relationships between different parts of the
design.
Software Engineering Software Design Slide 20
Modular Continuity
• A method satisfies this criterion if it leads to the
production of software such that a small change in the
problem specification leads to a change in just one (or a
small number of ) modules.
• EXAMPLE. Some projects enforce the rule that no
numerical or textual literal should be used in programs:
only symbolic constants should be used
• COUNTER EXAMPLE. Static arrays (as opposed to
open arrays) make this criterion harder to satisfy.
Software Engineering Software Design Slide 21
Modular Protection
• A method satisfied this criterion if it yields
architectures in which the effect of an abnormal
condition at run-time only effects one (or very few)
modules
• EXAMPLE. Validating input at source prevents errors
from propagating throughout the program.
• COUNTER EXAMPLE. Using int types where
subrange or short types are appropriate.
Software Engineering Software Design Slide 22
Five principles for Good Design
• From the discussion above, we can distil five
principles that should be adhered to:
– Linguistic modular units;
– Few interfaces;
– Small interfaces
– Explicit interfaces;
– Information hiding.
Software Engineering Software Design Slide 23
Linguistic Modular Units
• A programming language (or design language) should
support the principle of linguistic modular units:
– Modules must correspond to linguistic units in the language used
• EXAMPLE. Java methods and classes
• COUNTER EXAMPLE. Subroutines in BASIC are called
by giving a line number where execution is to proceed
from; there is no way of telling, just by looking at a section
of code, that it is a subroutine.
Software Engineering Software Design Slide 24
Few Interfaces
• This principle states that the overall number of
communication channels between modules
should be as small as possible:
– Every module should communicate with as few
others as possible.
• So, in the system with n modules, there may be
a minimum of n-1 and a maximum of links;
your system should stay closer to the minimum
2
)
1
( 
n
n
Software Engineering Software Design Slide 25
Few Interfaces
Software Engineering Software Design Slide 26
Small Interfaces (Loose Coupling)
• This principle states:
– If any two modules communicate, they should
exchange as little information as possible.
• COUNTER EXAMPLE. Declaring all instance
variables as public!
Software Engineering Software Design Slide 27
• A measure of the strength of the inter-connections
between system components.
• Loose coupling means component changes are
unlikely to affect other components.
– Shared variables or control information exchange lead
to tight coupling.
– Loose coupling can be achieved by state
decentralization (as in objects) and component
communication via parameters or message passing.
Coupling
Software Engineering Software Design Slide 28
Tight Coupling
Module A Module B
Module C Module D
Shared data
area
Software Engineering Software Design Slide 29
Loose Coupling
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
Software Engineering Software Design Slide 30
• Object-oriented systems are loosely coupled
because there is no shared state and objects
communicate using message passing.
• However, an object class is coupled to its
super-classes. Changes made to the attributes
or operations in a super-class propagate to all
sub-classes.
Coupling and Inheritance
Software Engineering Software Design Slide 31
Reusability
• A major obstacle to the production of cheap quality
software is the intractability of the reusability issue.
• Why isn’t writing software more like producing
hardware? Why do we start from scratch every time,
coding similar problems time after time after time?
• Obstacles:
– Economic;
– Organizational;
– Psychological.
Software Engineering Software Design Slide 32
Stepwise Refinement
• The simplest realistic design method, widely used in
practice.
• Not appropriate for large-scale, distributed systems:
mainly applicable to the design of methods.
• Basic idea is:
– Start with a high-level spec of what a method is to achieve;
– Break this down into a small number of problems (usually no
more than 10)
– For each of these problems do the same;
– Repeat until the sub-problems may be solved immediately.
Software Engineering Software Design Slide 33
Explicit Interfaces
• If two modules must communicate, they must do
it so that we can see it:
– If modules A and B communicate, this must be
obvious from the text of A or B or both.
• Why? If we change a module, we need to see
what other modules may be affected by these
changes.
Software Engineering Software Design Slide 34
Information Hiding
• This principle states:
– All information about a module, (and particularly how the
module does what it does) should be private to the module
unless it is specifically declared otherwise.
• Thus each module should have some interface, which
is how the world sees it anything beyond that interface
should be hidden.
• The default Java rule:
– Make everything private
Software Engineering Software Design Slide 35
Cohesion
A measure of how well a component “fits
together”.
• A component should implement a single logical
entity or function.
• Cohesion is a desirable design component
attribute as when a change has to be made, it
is localized in a single cohesive component.
• Various levels of cohesion have been identified.
Software Engineering Software Design Slide 36
Cohesion Levels
• Coincidental cohesion (weak)
– Parts of a component are simply bundled together.
• Logical association (weak)
– Components which perform similar functions are
grouped.
• Temporal cohesion (weak)
– Components which are activated at the same time
are grouped.
Software Engineering Software Design Slide 37
Cohesion Levels
• Communicational cohesion (medium)
– All the elements of a component operate on the same input or
produce the same output.
• Sequential cohesion (medium)
– The output for one part of a component is the input to
another part.
• Functional cohesion (strong)
– Each part of a component is necessary for the execution of a
single function.
• Object cohesion (strong)
– Each operation provides functionality which allows object
attributes to be modified or inspected.
Software Engineering Software Design Slide 38
Cohesion as a Design Attribute
• Not well-defined. Often difficult to classify
cohesion.
• Inheriting attributes from super-classes
weakens cohesion.
– To understand a component, the super-classes
as well as the component class must be
examined.
– Object class browsers assist with this process.

More Related Content

PPT
5 software design
PPT
PPT
Software Design vs. Software Architecture
PDF
Software Design and Architecture - 1 -Chapter One.pdf
PPT
Software Engineering Lec 8-design-
PPT
Object oriented sad-5 part i
PPTX
1605162990-week56.pptx
PPT
SE-4 software engineering nekdnhjnrindnj
5 software design
Software Design vs. Software Architecture
Software Design and Architecture - 1 -Chapter One.pdf
Software Engineering Lec 8-design-
Object oriented sad-5 part i
1605162990-week56.pptx
SE-4 software engineering nekdnhjnrindnj

Similar to SE-software design.ppt (20)

PPT
Architecture presentation 4
PPTX
EContent_11_2024_04_24_08_30_24_Unit3_PPTpptx__2024_04_05_09_12_25.pptx
PPTX
unit 3 Design 1
PPTX
Software Eng S3 ( Software Design ).pptx
PPTX
Design Engineering and Design concepts
PPTX
Unit 5 design engineering ssad
PPT
unit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDppt
PDF
PPTX
Design Concepts in Software Engineering-1.pptx
PPT
UNIT-4design-concepts-se-pressman-ppt.PPT
PDF
SE UNIT-3.pdf
PPTX
test.pptx
PPTX
Chapter five software Software Design.pptx
PPTX
Chapter 5 Software Design of software engineering.pptx
PPTX
Chapter five software Software Design.pptx
ODP
Software design
PPT
Software design
PPTX
Machine Learning in Software Engineering
PPT
Chapter 6 design
PPTX
design concepts in software engineering.pptx
Architecture presentation 4
EContent_11_2024_04_24_08_30_24_Unit3_PPTpptx__2024_04_05_09_12_25.pptx
unit 3 Design 1
Software Eng S3 ( Software Design ).pptx
Design Engineering and Design concepts
Unit 5 design engineering ssad
unit-iipart-1.WDQWDQWDQWDQWDQWDQWDQWDQWDQWDppt
Design Concepts in Software Engineering-1.pptx
UNIT-4design-concepts-se-pressman-ppt.PPT
SE UNIT-3.pdf
test.pptx
Chapter five software Software Design.pptx
Chapter 5 Software Design of software engineering.pptx
Chapter five software Software Design.pptx
Software design
Software design
Machine Learning in Software Engineering
Chapter 6 design
design concepts in software engineering.pptx
Ad

More from vishal choudhary (20)

PPTX
mobile application using automatin using node ja java on
PPTX
mobile development using node js and java
PPTX
Pixel to Percentage conversion Convert left and right padding of a div to per...
PPTX
esponsive web design means that your website (
PPTX
function in php using like three type of function
PPTX
data base connectivity in php using msql database
PPTX
software evelopment life cycle model and example of water fall model
PPTX
software Engineering lecture on development life cycle
PPTX
strings in php how to use different data types in string
PPTX
OPEN SOURCE WEB APPLICATION DEVELOPMENT question
PPTX
web performnace optimization using css minification
PPTX
web performance optimization using style
PPTX
Data types and variables in php for writing and databse
PPTX
Data types and variables in php for writing
PPTX
Data types and variables in php for writing
PPTX
sofwtare standard for test plan it execution
PPTX
Software test policy and test plan in development
PPTX
function in php like control loop and its uses
PPTX
introduction to php and its uses in daily
PPTX
data type in php and its introduction to use
mobile application using automatin using node ja java on
mobile development using node js and java
Pixel to Percentage conversion Convert left and right padding of a div to per...
esponsive web design means that your website (
function in php using like three type of function
data base connectivity in php using msql database
software evelopment life cycle model and example of water fall model
software Engineering lecture on development life cycle
strings in php how to use different data types in string
OPEN SOURCE WEB APPLICATION DEVELOPMENT question
web performnace optimization using css minification
web performance optimization using style
Data types and variables in php for writing and databse
Data types and variables in php for writing
Data types and variables in php for writing
sofwtare standard for test plan it execution
Software test policy and test plan in development
function in php like control loop and its uses
introduction to php and its uses in daily
data type in php and its introduction to use
Ad

Recently uploaded (20)

PDF
Pre independence Education in Inndia.pdf
PDF
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
PDF
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
PPTX
IMMUNITY IMMUNITY refers to protection against infection, and the immune syst...
PPTX
Final Presentation General Medicine 03-08-2024.pptx
PPTX
master seminar digital applications in india
PDF
grade 11-chemistry_fetena_net_5883.pdf teacher guide for all student
PPTX
1st Inaugural Professorial Lecture held on 19th February 2020 (Governance and...
PPTX
Microbial diseases, their pathogenesis and prophylaxis
PDF
102 student loan defaulters named and shamed – Is someone you know on the list?
PDF
Supply Chain Operations Speaking Notes -ICLT Program
PDF
O7-L3 Supply Chain Operations - ICLT Program
PDF
VCE English Exam - Section C Student Revision Booklet
PPTX
school management -TNTEU- B.Ed., Semester II Unit 1.pptx
PDF
FourierSeries-QuestionsWithAnswers(Part-A).pdf
PDF
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
PDF
Anesthesia in Laparoscopic Surgery in India
PPTX
PPT- ENG7_QUARTER1_LESSON1_WEEK1. IMAGERY -DESCRIPTIONS pptx.pptx
PDF
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
PPTX
Lesson notes of climatology university.
Pre independence Education in Inndia.pdf
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
IMMUNITY IMMUNITY refers to protection against infection, and the immune syst...
Final Presentation General Medicine 03-08-2024.pptx
master seminar digital applications in india
grade 11-chemistry_fetena_net_5883.pdf teacher guide for all student
1st Inaugural Professorial Lecture held on 19th February 2020 (Governance and...
Microbial diseases, their pathogenesis and prophylaxis
102 student loan defaulters named and shamed – Is someone you know on the list?
Supply Chain Operations Speaking Notes -ICLT Program
O7-L3 Supply Chain Operations - ICLT Program
VCE English Exam - Section C Student Revision Booklet
school management -TNTEU- B.Ed., Semester II Unit 1.pptx
FourierSeries-QuestionsWithAnswers(Part-A).pdf
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
Anesthesia in Laparoscopic Surgery in India
PPT- ENG7_QUARTER1_LESSON1_WEEK1. IMAGERY -DESCRIPTIONS pptx.pptx
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
Lesson notes of climatology university.

SE-software design.ppt

  • 1. Software Engineering Software Design Slide 1 Software Engineering Software Design
  • 2. Software Engineering Software Design Slide 2 Software Design Deriving a solution which satisfies software requirements
  • 3. Software Engineering Software Design Slide 3 Stages of Design • Problem understanding – Look at the problem from different angles to discover the design requirements. • Identify one or more solutions – Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources. • Describe solution abstractions – Use graphical, formal or other descriptive notations to describe the components of the design. • Repeat process for each identified abstraction until the design is expressed in primitive terms.
  • 4. Software Engineering Software Design Slide 4 The Design Process • Any design may be modelled as a directed graph made up of entities with attributes which participate in relationships. • The system should be described at several different levels of abstraction. • Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary.
  • 5. Software Engineering Software Design Slide 5 Phases in the Design Process Ar chitectur al design Abstr act specifica tio n Interface design Component design Da ta structur e design Algorithm design System architectur e Softw are specifica tion Interface specifica tion Component specifica tion Da ta structur e specifica tion Algorithm specifica tion Requir ements specifica tion Design acti vities Design pr oducts
  • 6. Software Engineering Software Design Slide 6 Design Phases • Architectural design: Identify sub-systems. • Abstract specification: Specify sub-systems. • Interface design: Describe sub-system interfaces. • Component design: Decompose sub-systems into components. • Data structure design: Design data structures to hold problem data. • Algorithm design: Design algorithms for problem functions.
  • 7. Software Engineering Software Design Slide 7 Design • Computer systems are not monolithic: they are usually composed of multiple, interacting modules. • Modularity has long been seen as a key to cheap, high quality software. • The goal of system design is to decode: – What the modules are; – What the modules should be; – How the modules interact with one-another
  • 8. Software Engineering Software Design Slide 8 Modular programming • In the early days, modular programming was taken to mean constructing programs out of small pieces: “subroutines” • But modularity cannot bring benefits unless the modules are – autonomous, – coherent and – robust
  • 9. Software Engineering Software Design Slide 9 Procedural Abstraction • The most obvious design methods involve functional decomposition. • This leads to programs in which procedures represent distinct logical functions in a program. • Examples of such functions: – “Display menu” – “Get user option” • This is called procedural abstraction
  • 10. Software Engineering Software Design Slide 10 Programs as Functions • Another view is programs as functions: input output x  f  f (x) the program is viewed as a function from a set I of legal inputs to a set O of outputs. • There are programming languages (ML, Miranda, LISP) that directly support this view of programming Well-suited to certain application domains - e.g., compilers Less well-suited to distributed, non- terminating systems - e.g., process control systems, operating systems like WinNT, ATM machines
  • 11. Software Engineering Software Design Slide 11 Object-oriented design – The system is viewed as a collection of interacting objects. – The system state is decentralized and each object manages its own state. – Objects may be instances of an object class and communicate by exchanging methods.
  • 12. Software Engineering Software Design Slide 12 Five Criteria for Design Methods • We can identify five criteria to help evaluate modular design methods: – Modular decomposability; – Modular composability; – Modular understandability; – Modular continuity; – Modular protection.
  • 13. Software Engineering Software Design Slide 13 Modular Decomposability • This criterion is met by a design method if the method supports the decomposition of a problem into smaller sub-problems, which can be solved independently. • In general method will be repetitive: sub- problems will be divided still further • Top-down design methods fulfil this criterion; stepwise refinement is an example of such method
  • 14. Software Engineering Software Design Slide 14 Hierarchical Design Structure System level Sub-system level
  • 15. Software Engineering Software Design Slide 15 Top-down Design • In principle, top-down design involves starting at the uppermost components in the hierarchy and working down the hierarchy level by level. • In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.
  • 16. Software Engineering Software Design Slide 16 Modular Composability • A method satisfies this criterion if it leads to the production of modules that may be freely combined to produce new systems. • Composability is directly related to the issue of reusability • Note that composability is often at odds with decomposability; top-down design, – for example, tends to produce modules that may not be composed in the way desired • This is because top-down design leads to modules which fulfil a specific function, rather than a general one
  • 17. Software Engineering Software Design Slide 17 Examples • The Numerical Algorithm Group (NAG) libraries contain a wide range of routines for solving problems in linear algebra, differential equations, etc. • The Unix shell provides a facility called a pipe, written “”, whereby – the standard output of one program may be redirected to the standard input of another; this convention favours composability.
  • 18. Software Engineering Software Design Slide 18 Modular Understandability • A design method satisfies this criterion if it encourages the development of modules which are easily understandable. • COUNTER EXAMPLE 1. Take a thousand lines program, containing no procedures; it’s just a long list of sequential statements. Divide it into twenty blocks, each fifty statements long; make each block a method. • COUNTER EXAMPLE 2. “Go to” statements.
  • 19. Software Engineering Software Design Slide 19 Understandability • Related to several component characteristics – Can the component be understood on its own? – Are meaningful names used? – Is the design well-documented? – Are complex algorithms used? • Informally, high complexity means many relationships between different parts of the design.
  • 20. Software Engineering Software Design Slide 20 Modular Continuity • A method satisfies this criterion if it leads to the production of software such that a small change in the problem specification leads to a change in just one (or a small number of ) modules. • EXAMPLE. Some projects enforce the rule that no numerical or textual literal should be used in programs: only symbolic constants should be used • COUNTER EXAMPLE. Static arrays (as opposed to open arrays) make this criterion harder to satisfy.
  • 21. Software Engineering Software Design Slide 21 Modular Protection • A method satisfied this criterion if it yields architectures in which the effect of an abnormal condition at run-time only effects one (or very few) modules • EXAMPLE. Validating input at source prevents errors from propagating throughout the program. • COUNTER EXAMPLE. Using int types where subrange or short types are appropriate.
  • 22. Software Engineering Software Design Slide 22 Five principles for Good Design • From the discussion above, we can distil five principles that should be adhered to: – Linguistic modular units; – Few interfaces; – Small interfaces – Explicit interfaces; – Information hiding.
  • 23. Software Engineering Software Design Slide 23 Linguistic Modular Units • A programming language (or design language) should support the principle of linguistic modular units: – Modules must correspond to linguistic units in the language used • EXAMPLE. Java methods and classes • COUNTER EXAMPLE. Subroutines in BASIC are called by giving a line number where execution is to proceed from; there is no way of telling, just by looking at a section of code, that it is a subroutine.
  • 24. Software Engineering Software Design Slide 24 Few Interfaces • This principle states that the overall number of communication channels between modules should be as small as possible: – Every module should communicate with as few others as possible. • So, in the system with n modules, there may be a minimum of n-1 and a maximum of links; your system should stay closer to the minimum 2 ) 1 (  n n
  • 25. Software Engineering Software Design Slide 25 Few Interfaces
  • 26. Software Engineering Software Design Slide 26 Small Interfaces (Loose Coupling) • This principle states: – If any two modules communicate, they should exchange as little information as possible. • COUNTER EXAMPLE. Declaring all instance variables as public!
  • 27. Software Engineering Software Design Slide 27 • A measure of the strength of the inter-connections between system components. • Loose coupling means component changes are unlikely to affect other components. – Shared variables or control information exchange lead to tight coupling. – Loose coupling can be achieved by state decentralization (as in objects) and component communication via parameters or message passing. Coupling
  • 28. Software Engineering Software Design Slide 28 Tight Coupling Module A Module B Module C Module D Shared data area
  • 29. Software Engineering Software Design Slide 29 Loose Coupling Module A A’s data Module B B’s data Module D D’s data Module C C’s data
  • 30. Software Engineering Software Design Slide 30 • Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing. • However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes. Coupling and Inheritance
  • 31. Software Engineering Software Design Slide 31 Reusability • A major obstacle to the production of cheap quality software is the intractability of the reusability issue. • Why isn’t writing software more like producing hardware? Why do we start from scratch every time, coding similar problems time after time after time? • Obstacles: – Economic; – Organizational; – Psychological.
  • 32. Software Engineering Software Design Slide 32 Stepwise Refinement • The simplest realistic design method, widely used in practice. • Not appropriate for large-scale, distributed systems: mainly applicable to the design of methods. • Basic idea is: – Start with a high-level spec of what a method is to achieve; – Break this down into a small number of problems (usually no more than 10) – For each of these problems do the same; – Repeat until the sub-problems may be solved immediately.
  • 33. Software Engineering Software Design Slide 33 Explicit Interfaces • If two modules must communicate, they must do it so that we can see it: – If modules A and B communicate, this must be obvious from the text of A or B or both. • Why? If we change a module, we need to see what other modules may be affected by these changes.
  • 34. Software Engineering Software Design Slide 34 Information Hiding • This principle states: – All information about a module, (and particularly how the module does what it does) should be private to the module unless it is specifically declared otherwise. • Thus each module should have some interface, which is how the world sees it anything beyond that interface should be hidden. • The default Java rule: – Make everything private
  • 35. Software Engineering Software Design Slide 35 Cohesion A measure of how well a component “fits together”. • A component should implement a single logical entity or function. • Cohesion is a desirable design component attribute as when a change has to be made, it is localized in a single cohesive component. • Various levels of cohesion have been identified.
  • 36. Software Engineering Software Design Slide 36 Cohesion Levels • Coincidental cohesion (weak) – Parts of a component are simply bundled together. • Logical association (weak) – Components which perform similar functions are grouped. • Temporal cohesion (weak) – Components which are activated at the same time are grouped.
  • 37. Software Engineering Software Design Slide 37 Cohesion Levels • Communicational cohesion (medium) – All the elements of a component operate on the same input or produce the same output. • Sequential cohesion (medium) – The output for one part of a component is the input to another part. • Functional cohesion (strong) – Each part of a component is necessary for the execution of a single function. • Object cohesion (strong) – Each operation provides functionality which allows object attributes to be modified or inspected.
  • 38. Software Engineering Software Design Slide 38 Cohesion as a Design Attribute • Not well-defined. Often difficult to classify cohesion. • Inheriting attributes from super-classes weakens cohesion. – To understand a component, the super-classes as well as the component class must be examined. – Object class browsers assist with this process.