SW Design & Architecture

Software Design
• Software design is a mechanism to transform user requirements (as
described in software requirements specifications) into some suitable
form, which helps the programmer in software coding and
implementation.

• In software design, we consider the system to be a set of components

or modules with clearly defined behaviors & boundaries.
Software Design
• External design - focuses on which modules are needed, their
specifications, relationship and interface among them

• Internal design - focuses on planning and specifying the internal

structure and processing detail
SW Design Principles
• Software design principles are concerned with providing means to
handle the complexity of the design process effectively.

• Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors
during design.
SW Design Principles
Problem Partitioning
• For small problem, we can handle the entire problem at once but for
the significant problem, divide the problems and conquer the problem
it means to divide the problem into smaller pieces so that each piece
can be captured separately.

• For software design, the goal is to divide the problem into manageable
pieces.
Abstraction
• An abstraction is a tool that enables a designer to consider a
component at an abstract level without bothering about the internal
details of the implementation.

• Common abstraction mechanisms: Functional Abstraction, Data

Abstraction
Functional Abstraction

• A module is specified by the method it performs.

• The details of the algorithm to accomplish the functions are not visible
to the user of the function.

• Forms the basis for Function oriented design approaches.

Data Abstraction

• Details of the data elements are not visible to the users of data.

• Data Abstraction forms the basis for Object Oriented design

approaches.
Modularity
• Modularity specifies to the division of software into separate modules
which are differently named and addressed and are integrated later on
in to obtain the completely functional software.

• Single large programs are difficult to understand and read due to a

large number of reference variables, control paths, global variables,
etc.
Desirable Properties of a Modular System

• Each module is a well-defined system that can be used with other

applications.
• Each module has single specified objectives.
• Modules can be separately compiled and saved in the library.
• Modules should be easier to use than to build.
• Modules are simpler from outside than inside.
Modular Design
• Modular design reduces the design complexity and results in easier
and faster implementation by allowing parallel development of
various parts of a system.
Functional Independence
• Functional independence is achieved by developing functions that perform only one
kind of task and do not excessively interact with other modules.

• Independence is important because it makes implementation more accessible and

faster.

• The independent modules are easier to maintain, test, and reduce error propagation
and can be reused in other programs as well.

• Thus, functional independence is a good design feature which ensures software

quality.
Functional Independence: measurement
criteria

• Cohesion: It measures the relative function strength of a module.

• Coupling: It measures the relative interdependence among modules.

Information Hiding
• Modules should be specified in such a way that data included within a
module is inaccessible to other modules that do not need for such
information.

• Provides the most significant benefits when modifications are required

during testing's and later during software maintenance.

• This is because as most data and procedures are hidden from other parts
of the software, inadvertent errors introduced during modifications are
less likely to propagate to different locations within the software.
Coupling and Cohesion
• The measure of interdependencies that exists between two modules of a software program is
called coupling.

• Coupling can be tight or loose.

• If the degree of dependencies in the program modules is higher, the coupling is said to be tight
coupling (strongly dependent).

• If the degree of dependencies is lesser in the program modules, the coupling is said to be loose.

• Uncoupled modules have no interdependence at all within them.

• A software program is considered good software if it possesses loose
coupling.

• Having loosely coupled modules will ensure that each module solves a
definite purpose.

• A loosely coupled module will be least dependent over the other

modules of the program.
• The code has weak cohesion because it does a lot of stuff
• Updates database
• Calculates profit
• Displays profits
• High coupling with the email object
• It goes deep in the email object structure to access data
• What happens if the email object structure is modified or changed?
• How do you fix the code?
• Pass only the data the fn needs instead of the entire email object
• Move the function inside the email object since it’s directly related
• Data coupling occurs when the modules of the programs communicate among
themselves by sharing the data, regularly through parameters.

• The data gets passed between the modules through the parameters by making
use of an argument list. While passing the parameters, it must be ensured that
all the parameters must be passed, and no parameter is dropped.

• Data coupling is better than stamp coupling, because the module takes exactly
what it needs, without the need of it knowing the structure of a particular
data structure.
•
Stamp Coupling

• When many modules of a software program share and communicate

among themselves using a composite data structure and use only a
part of it, stamp coupling occurs.

• In stamp coupling, an entire composite data structure is passed

between modules as a parameter and the receiving module use only a
few parameters in the received data structure.
• Control coupling occurs when one module controls the flow of
another by passing control information
• e.g., a control flag, a comparison function passed to a sort algorithm.
• “format” is a control coupling
flag
• Adding a new format
requires modifying export()
• SRP is also violated / low
cohesion
• Harder to extend core logic
Solution?
• Uses polymorphism
• Easy to add new exporter classes
• Easy to inject exporter as
dependency
External Coupling
• Occurs when multiple modules depend on an external interface /
system
• Changes on the external system forces changes to all dependent
modules.
• e.g. multiple modules accessing a database or an API directly
• Both classes depend on
app.db
• If the DB schema is changes
both modules break
• What happens if the
database is changed from
sqlite to Postgres?
• Hard to test (requires a live
database with correct
schema)
 Solution?
• Use a single interface
(data abstraction layer)
• Better yet, use an ORM
• Centralized query logic
• Only the abstraction
layer needs updating
during changes
Common Coupling
• Occurs when multiple modules share global data
• Changes to the shared data by one module may unpredictably affect
the others
• Makes the system hard to debug / maintain
• What happens to other
modules using the LOG_LEVEL
variable?
• What happens to unit tests that
depend on LOG_LEVEL
• Solution: Make LOG_LEVEL part
of the Logger class and inject
its value via the constructor
Content Coupling
• The worst kind of coupling and goes against core OO principles

• Content coupling, or pathological coupling, occurs when one module

modifies or relies on the internal workings of another module.

• Changing the inner working will lead to the need of changing the
dependent module.
• Violates encapsulation
• What happens if _salary is
changed to __salary in
Employee?
• Hard to maintain
Example Scenario
• Let’s say we have two modules in our application - order and
shipment
• One concept is common in both (i.e. product)
• This means both modules need some logic to handle product
concept
• Possible solutions:
• Create a product module to handle the product concept & and
couple the two modules to it
• Add product concept in both modules
• The second solution implies maintaining the same logic in two
different places.
• If product logic changes we modify both modules
• This is also considered as coupling (logical coupling)
• If product concept never changes there is no problem
• To the contrary, if concept changes frequently, extract to separate
module
• If more other modules use the product concept, extract to
separate module.
• In general, when coupling modules
• Couple modules only using the minimum amount of interfaces
needed.
• Pass only the minimum amount of parameters needed via the
interface(s).
• Pass only data and avoid altering the control flow of our
modules.
Object-Oriented Software Design
• Software design provides a design plan that describes the elements of a
system, how they fit, and work together to fulfill the requirement of the
system.
• The objectives of having a design plan are as follows −
• To negotiate system requirements, and to set expectations with
customers, marketing, and management personnel.
• Act as a blueprint during the development process.
• Guide the implementation tasks, including detailed design, coding,
integration, and testing.
• It comes before the detailed design, coding, integration, and testing and
after the domain analysis, requirements analysis, and risk analysis.
Cells and SW Objects (Alan Kay’s Metaphor)
• Like cells in biological systems, software objects don't know
what goes on inside one another, but they communicate and
work together to perform complex tasks.
• In contrast, monolithic software is like a mechanical clock
containing innumerable gears. Each gear functions
unintelligently and only in relation to other adjacent gears.
• That design is hopelessly flawed. "When you're building gear
clocks, eventually you reach a certain level of complexity and it
falls in on itself,".
Software Objects and Machines
• A software object may be machinelike, but, crafted by a
thoughtful designer, it can be very smart.
• It makes decisions; it does things and knows things.
• It collaborates with potentially many other objects.
• Living in an enclosing machine, it is a whole on one level and a
part on another.
• As with a machine, or a cell, the behaviors of an object are strictly
limited to those that are designed into it.
• Cells and objects follow programmed instructions.
• The dynamic behavior of a software system emerges from
the interactions of many objects—each contributing, each
playing a responsible role.
• All but the simplest of devices, both hardware and software,
are designed from parts. These parts interact according to
someone's plan.
• In a physical machine, these parts touch one another or
communicate through a shared medium. Their interactions
may give way to force, transfer motion, or conduct heat.
Object Machinery
• A software application is constructed from parts (similar to physical
machines).
• These parts—software objects—interact by sending messages to
request information or action from others.
• Throughout its lifetime, each object remains responsible for
responding to a fixed set of requests.
• To fulfill these requests, objects encapsulate scripted responses and
the information that they base them on.
• If an object is designed to remember certain facts, it can use them to
respond differently to future requests.
An Object
• Knows Information

• Performs Services

• Maintains Connections (to other objects)

• Makes Decisions (to do the right things)