The document discusses principles of software design such as separation of concerns, loose coupling, and high cohesion. It states that components should focus on separate tasks, have minimal interfaces, and be designed simply and autonomously to allow for easy extensibility. High coupling between modules makes the system inflexible since a change in one component could impact many others. The document emphasizes designing components that are loosely coupled, cohesive, and separated by concern to produce a flexible and adaptable software architecture.

1. 1

2. 2

3. 3

4.  Each component has all relevant features
within the abstraction; a general interface
can be reused.
4

5.  Each component has all the features needed
for a sensible and efficient usage within the
abstraction
 The interface is as small as possible.
 Minimum possible interface is to be selected
5

6.  All features of a components are easy to
understand (and implement);
 Complex features are built up of simpler
features.
6

7.  The decomposition of modules can be easily
and intuitively be understood
 Complexity is not a criteria for a good
software design.
7

8.  All the layers / subsystems should focus in same
problem set.
 Example:
 While calculating the annual interest on savings
bank should not include details about customer
Education!!!
8

9. 9
Presentation Layer/
GUI Layer
Business Logic
Data Layer

10.  Separation of concerns Principle
 Decomposition according to the
responsibilities within the system
 Components working on different tasks
should be separated
10

11.  Separation of concerns is a recognition of the
need for human beings to work within a
limited context
 The important factor is minimization of
interaction points to achieve high cohesion
and low coupling
11

12.  Web Content Management
 HTML represents abstract structure of the
document over the internet.
 CSS is used to separate data from style
 Two separate files are maintained i-e one for
Data (HTML) and other for style (CSS)
12

13.  Extensibility is the ease of adapting software
products to changes of specification.
13

14.  For small programs change is usually not a
difficult issue; but as software grows bigger, it
becomes harder and harder to adapt.
 A large software system often looks to its
maintainers as a giant house of cards in which
pulling out any one element might cause the
whole structure to collapse
14

15.  Design simplicity: a simple architecture will always be
easier to adapt to changes than a complex one
 Decentralization: the more autonomous the modules,
the higher the likelihood that a simple change will affect just
one module, or a small number of modules, rather than
changes over the whole system.
15

16.  Coupling
 This refers to how many dependencies there are between
modules and the nature of the links. A module which is
highly coupled means that it has to use many other modules
for its own functionality to work.
16

17. No dependencies Loosely coupled-some dependencies
Highly coupled-many dependencies
High coupling makes modifying parts
of the system difficult, e.g.,
modifying a component affects all
the components to which the
component is connected.