Software Design

Module Overview

Software
Design
Design
Patterns
Concepts
CONTEXT FOR SOFTWARE DESIGN
Software Design – Where does it fit?

Requirements Architecture Design

• Requirements provide • Architecture provides • Design provides
specification of specification of specification of
“WHAT” needs to be “HOW” software is to “HOW” developers
developed be designed need to CODE the
software

But both Architecture and

Design seem to answer
“HOW”. Then what is the
difference?
Example: No Arch, No Design, Only Code

// Authenticate user
printf(“Enter username:”);
scanf(“%s”,uname);
So, what’s wrong with this
printf(“Enter password:”); code?
scanf(“%s”,passwd);
status = AUTH_PENDING;
if( !strcmp(passwd,”#343idsk”))
status = “AUTH”;
else
status = “AUTH_FAIL”;
Example: First design then code
Design Code
1. Create a table in database
{
with username and // …
password printf(“Enter username:”);
2. Check password for given scanf(“%s”,uname);
username against password printf(“Enter password:”);
stored in the database scanf(“%s”,passwd);
status = AUTH_PENDING;
status = authenticate_user(uname, passwd);
// …
}
This is code with a proper
int authenticate_user(char u[], char pass[])
design looks much better, isn’t
{
it? // actualpass = select pass from user where uname = u
if( !strcmp(pass,actualpass) )
status = “AUTH”;
else
status = “AUTH_FAIL”;
return status;
}
Example: Architecture + Design + Code
Architecture (Principles!) Design
1. Applications must not implement 1. Accept userid / password from user
their own user management 2. Invoke authentication_service
code
2. All applications must only use a
centralized LDAP-based service
for both authentication and
authorization
3. ActiveDirectory-based services Code
are to be used
{
// …
printf(“Enter username:”);
Ah, thanks to the architecture scanf(“%s”,uname);
principles, NONE of my printf(“Enter password:”);
applications need to scanf(“%s”,passwd);
status = AUTH_PENDING;
implement authentication logic
status = authentication_service(uname, passwd);
// …
}
The Big Questions

So, is design Is architecture

mandatory for mandatory for
writing code? creating design?
Requirements-Driven Design (RDD)

Key drivers for

• The designer tries to RDD • Benefit of good design
create the most limited to one
optimum solution that • Ease of coding application
is specific to the • Fast turn-around • Cannot leverage best
application practices found in other
requirements applications (crudely-
put, “no reuse”)

Key drawbacks
RDD Strategy
of RDD
Architecture-Driven Design (ADD)

• Designer tries to leverage Key drivers • Design may get constrained

the “ready-to-use” wisdom by “least common
and guidelines provided by • Same stakeholders denominator” of
architecture architecture
• Provide time-saving options engaged with multiple • Requires up-front
applications
for coding phase • Leverage “certified” pre- investment of resources
• Leverage others’ expertise • ROI will come only “later”
existing assets
for non-core activities

ADD Key
Strategy drawbacks
What is the verdict?

C – ????
Architecture
ADC – ????
AC AD
AC – ???? ADC

AD – ???? Code DC Design

C
DC – ????
What is the verdict?
C – Not desirable

ADC – Ideal Architecture

AC – Better than nothing! AD

AC
ADC
AD – Plan for the future
Code DC Design
DC – Good for one-off applications C
SOFTWARE DESIGN PRACTICES
Background to Design practices
• Design involves thinking through
the “how” BEFORE the coding
• If “A” is there, it can help
• Not all design decisions are driven
by architecture alone (Example?)
Major Goals of Software Design

Functional • As per SRS

Requirements

• Performance
• Security
Quality •
•
Scalability
Usability
Attributes • Maintainability
• Flexibility
Achieving Correctness
• What is correctness?
• How to incorporate correctness into design?
• How to incorporate correctness into code?
Achieving Correctness

• Translate informal requirements to

What is “specification”
correctness? • Incorporate “specification” into design

Design elements • Pre/Post Conditions

for correctness • Invariants

How to incorporate • Test driven development

correctness into • Compiler enforced invariants (e.g.,
code? assertions)
Achieving Robustness

What is robustness?
• Ability to be resilient when there are errors

How to incorporate robustness into design?

• Specify exceptional flows
• Exception class hierarchy
• Validation mechanism into method

How to incorporate robustness into code?

• Defensive Programming (input checking, etc.)
• Logging
Flexibility
• The myth of “frozen requirements”
• Goals of Flexibility
– Adding more or the same (adding bank accounts)
– Adding new functionality (export in lists)
• How to incorporate flexibility into design?
Reusability
• Compile time reusability
• Run time reusability

How is this different

from Ctrl-C Ctrl-V
Reuse?!!!
Software Design Concepts

Modularity Reusability Coupling Cohesion

Modularity
What is modularity?

• Partitioning solution into “small” modules

• Top-down vs Bottom-up

Benefits

• Makes software testable

• Localizes impact of changes
• Increases reusability

Watch out

• Coupling-Cohesion tradeoff
• More coding, more documentation
• More testable units, more bug possibilities
• Performance impact due to long call-chains
Reusability

What is reusability?

• Ability for same module to be used elsewhere

• Static reusability vs Dynamic reusability

Benefits

• Reduces software development time

• Reduces defects in software

Watch out

• Resistance to using “others” code

• External dependence (obsolescence, maintenance)
Coupling

What is coupling?

• Degree of interdependence between modules

• Measure of dependency among the modules

High coupling

• Increases dependency among modules

• Reduces reusability
• Increases complexity

Low coupling

• Reduced dependency increases reusability

• May increase code size
Types of coupling

Reference:
https://www.javatpoint.com/software-engineering-coupling-and-cohesion
Types of coupling
• Data coupling
– Data is passed around for “information processing”
• Stamp coupling
– Passing large objects across modules (‘god object’)
• Control coupling
– One module’s data is used to drive execution control
• External coupling
– Dependency on external formats, protocols, services
• Common coupling
– Impacted by a common global data item
• Content coupling
– Inverse of control coupling (conditional branching into other modules)
Cohesion

What is cohesion?

• Degree to which different functions of WITHIN a module are focused on a

single objective

Benefits

• Improves consistency
• Increase reuse
• Plug-and-play
• Engineering eases (development and testing)
• Localization of expertise

Watch out

• Not all types of cohesion are beneficial

Binding forces of cohesion

Logical All functions pertaining to payments

Temporal Init of DB + Init of Web server + Init O/S

Loan processing (verification + evaluation +

Procedural underwriting)

I/O oriented PO printing + PO saving + PO mailing

Output of one chained to input of another
Sequential (Search  Select  Add  Checkout)

Functional Self-contained (search to payment)

SOFTWARE DESIGN PROCESS
Design Strategies

Incremental
Templates and
Decomposition Composition and
Patterns
evolutionary
Decomposition
Decomposition Example

Overall design problem

• Secure transmission of packs

Decompose design problem

• Non-tamperability of packs
• Secrecy of packs

Solve sub-problems
• Check-sums of packs
• Encryption of packs

Overall design solution

• Use MD5 encryption with secure FTP
Composition
Composition Example

Overall design problem

• Secure transmission of packs

Identify components available

• Secure FTP
• HTTPS
• Blockchain

Assemble solution suitable components

• Secure FTP
• HTTPS
Incremental

Similar to decomponsition
approach but solutions are
assembled incrementally.
Templates and Patterns
Pattern Repository Design

Pattern #1
Configure Design for
Pattern #2
Problem #1
Pattern #3
Pattern #4
Configure Design for
Problem #2

Patterns

Design Architecture
Patterns Patterns
Design Patterns
• Incorporates best practices to achieve design
goals
• Each pattern satisfies one or more design goals
• Learning to use design patterns involves:
– Learning how to implement the pattern
– Learning to identify which pattern to use when
Patterns in Architecture
Persistent Concurrent Lots of UI
Lots of Data
Data Users Screens

Large User Complex

Integrations
Base Logic

• Distilled wisdom
• Learnt and perfected over years
• Expressed in Problem / Solution format
• Alexander, Christopher (1977).
A Pattern Language: Towns, Buildings, Constructio
n
Recap: Software Design

How it needs to be done

• Guide to programmers
How
What needs to be done
What
• Give some freedom to programmers

Gives software a lot of character!

• Flexibility, extensibility,
Understandability, standardized
OBJECT-ORIENTATION
Outline
• Recap of Object-Orientation
• Introduction to Design Patterns
• The Pattern Catalog
• The Patterns – one at a time!
Pillars of Object-Orientation

Abstraction Encapsulation Inheritance Polymorphism

Pillars of Object-Orientation

Abstraction Encapsulation Inheritance Polymorphism

Information
Classes and hiding with Overriding
Subclasses
objects Access methods
Specifiers

Generalization
Members Interface for
vs
Variables client access
Specialization

Single vs
Methods
Multiple
Design Principle Examples
• Identify the aspects that vary and separate them
from what stays the same
• Classes should be open for extension and closed
for modification
• Code using abstractions not on the concrete
GOING FORWARD
Looking ahead