Design Principles

Asanka Sanjaya | hmasanjaya@gmail.com

1
Causes of
difficulties in
software design

2
Causes of difficulties
● Software development is complicated and difficult.
● Design is one of the most difficult tasks in software development
● To understand why software development is difficult, we can use Brooks’ four
essences of difficulties of software development.

3
Brooks’ four essences of difficulties of software
development
● Complexity
● Conformity
● Changeability
● Invisibility

4
Complexity
● Software systems are complex.
● The complexity of the problem to be solved by software causes difficulty in
communication between users and developers, which leads to errors in
requirements elicitation and specifications, and consequently, developing
wrong software.
● Also, the complexity of the structure of software systems makes
modifications of software difficult; hence software is hard to extend with new
functions.

5
Conformity
● Software is expected to conform to the standards imposed by other
components, such as hardware, or by external bodies, or by existing
software.
● A missing semicolon or other syntactic error can be detected by a compiler.
But, a defect in the program logic or a timing error may be difficult to detect
when encountered during operation.

6
Changeability
● Software suffers constant need for change.
● Changing one part of a software system often results in undesired side
effects in other parts of the system, requiring more changes before the
software can operate at maximum efficiency.
● This makes software is very hard to change.
● Complexity and the need for conformity can make changing software an
extremely difficult task.

7
Invisibility
● Software is said to be invisible because it has no physical properties.
● While the effects of executing software on a digital computer are observable,
software itself cannot be seen, tasted, smelled, touched, or heard.
● Because software has no physical presence, software engineers must use
different representations at different levels of abstraction in an attempt to
visualize the inherently invisible entity.

8
Vehicles to overcome
difficulties

9
Vehicles to overcome difficulties
● The Axiom of Separation of Concerns
● The Axiom of Comprehension
● The Axiom of Translation
● The Axiom of Transformation

10
The Axiom of Separation of Concerns
● A complex problem can best be solved by initially devising an intermediate
solution expressed in terms of simpler independent problems.
● The simpler problems that we identify must collectively solve the original
problem.
● The simpler problems must be independent.

11
The Axiom of Comprehension
● The mind cannot easily manipulate more than about seven things at a time.
● This axiom is widely known as the Rule of Seven Plus or Minus Two.
● It is derived from the discovery in the 1950s that humans have a limitation on
short term memory.
● We humans are overwhelmed when given a large number of independent
units of information.

12
The Axiom of Translation
● Design correctness is unaffected by movement between equivalent contexts.
● A correct design that meets its interface and behaviour specifications in one
environment will continue to meet its specifications despite a change in
environment, provided that the new environment provides equivalent services.
● Ex: if a new version of an operating system replaces an old version, and if it
promises to initiate our application program, and to provide the same services
when we call for them, then, our application program will produce the same
results as before.

13
Basic rules of
software design

14
Basic rules of software design
● We already know some tools and methods which should be used in software
design.
● Now, the question is how to use these tools effectively.
● By referring to Witt, Baker and Merritt proposed five principles we can
summarize the principles which form the basic rules of software design.
○ The principle of modular designs
○ The principle of portable designs
○ The principle of malleable designs
○ The principle of intellectual control
○ The Principle of visualisation

15
The principle of modular designs
● Modularity can be achieved by dividing large aggregates of components into
units having loose inter-unit coupling and high internal cohesion.
● Unrelated parts of the system should be separated, and related parts of the
system should be grouped together.
● Separating unrelated components decreases the chance that modifying one
component will adversely impact the other.
● Putting related parts together makes it easier to see the relationships
between them when debugging them or adding functionality to them.

16
The principle of portable designs
● Portability can be achieved by employing abstract context interfaces.

17
The principle of malleable designs
● Malleability(flexibility or modifiability) can be achieved with designs that
model the end-user’s view of the external environment.

18
The principle of conceptual integrity
● The system should appear to reflect the mind of a single person and to
faithfully adhere to single concept.
● Conceptual integrity can be achieved by uniform application of a limited
number of design forms.

19
The principle of intellectual control
● The design process should be under intellectual control.
● Intellectual control can be achieved by recording designs (after developing a
design strategy) as hierarchies of increasingly detailed abstractions.

20
The Principle of visualisation
● Visibility can be achieved (or partially achieved) by representing designs in
visual notations such as diagrams, pictures and figures, etc. to express the
characteristics of the behaviour of system components and the relationships
between the components.

21
Software
Development
processes and
Design processes
22
Software Development processes and Design
processes
● A wide range of activities are involved in software design.
● A process model describes the activities involved in the design process and
the interrelationships between the activities.

23
The Waterfall Software Process

24
V model

25
V model
● V model is an industrial standard version of a ‘waterfall’ model.
● The input of software design: It includes functional specification and
nonfunctional requirements as the result of requirements analysis and
functional specification phases.
● The output of software design: It includes the design specification that
describes software architecture and module design which describes the
design of the components in the software. These outputs are used for
programmers to implement modules, for testers to perform unit and
integration tests.

26
Spiral model

27
Spiral model
● Each stage in the spiral model involves the following activities.
○ The objectives of the stage are identified;
○ The options and constraints are listed and explored;
○ The risks involved in choosing between these options are evaluated;
○ A plan for how to proceed to the next stage is determined

28
Design strategies

29
Design strategies
● A number of design strategies have been advanced in the literature and used
in various design methods to guide the process of building up design models.
○ Decompositional methods
○ Compositional methods
○ Template-based
○ Evolutionary strategies

30
Decompositional design strategy

31
Decompositional design strategy
● Decompositional methods take a top-down approach to the design process.
● It starts with an original description of the problem or a model of the original
problem.
● This original problem is, then, decomposed into a number of sub-problems.
● These sub-problems are then solved separately.
● If a sub-problem is still too complicated to be solved directly, it is further
decomposed until it is simple enough to be solved directly.

32
Compositional design strategy

33
Compositional design strategy cont...
● Compositional strategy starts the building of a model identifying a set of
particular entities or objects involved in the problem.
● These entities and objects are described, classified and grouped.
● For each group, the relationships between the entities are identified so that
links between entities are established.
● The relationships between the components are identified to make larger
components.

34
Design template and design reuse
● Over many years of research and practices in software development, people
find that for a certain type of problem in a certain application domain, there
may be a great deal of similarities in the designs that are proved to be
effective.
● If such similarities can be abstracted into a template of design, then once a
problem is identified to be an instance of such a class of problems, the design
template can be instantiated and a good design can be relatively easily
obtained.

35
Incremental and evolutionary design strategies
● Trial-and-error is perhaps the most basic approach to all designs.
● It involves the creation of a design and the evaluation of the design against
the requirements and constraints.
● If some requirements and/or constraints are not satisfied, the design is
modified and a new design, even new designs, created.
● The cycle of creation and evaluation stops until a satisfactory design is
obtained.
● However, there is no guarantee that a satisfactory design can always be
obtained.

36