Software Design and

Architecture
by
Prof.Jayanthi.R
Module - 1
 module - 1
Design Fundamentals
• The nature of Design process
– Objectives
– Building Modules,
– Constructs,
– Design qualities,
– Assessing the design,
– Design viewpoints for software.
• Design practices
- Analysis on design requirements
- Designing with quality factors
- Coupling
- Cohesion and cognitive dimensions
• Measure Quality attributes and assessment
• Case studies
 THE NATURE OF DESIGN
PROCESS
1.1 What is design?
1.2 The role of the design activity process
1.3 Design as a problem-solving
1.4 Design as a ‘wicked’ problem
What is design?
 What is design? – cont..
Design
• Artifacts (work of the art)/Manufactured Article - products
developed and created by human beings.
• All the products are in some form of design process – whether
a good one or a poor one.
– Cars
– Trains
– Airplanes
– Houses
– Washing machines
– Television sets
– Chairs
– Shoes
 What is design? – cont...
• Good design is necessary for all the
products that are developed.
• Design is not only the production of
artifacts but also the
fabrication(construction) process.
• If good design may be marred (spoiled)
by poor fabrication, then constructional
skill can disguise (cover up) for the poor
design.
 What is design? – cont...
• In the domain of computing science and
software engineering, designing
software is a major problem-solving
technique.
• So what is design exactly?
• what sort of activities does it involve?
• what can we observe about the products
of that process?
 Description of the design process
by J. Christopher Jones
• The fundamental problem is that “designers
are appreciative to use current information to
predict a future state” but that will not come
near their predictions are correct.
• The final outcome of designing has to be
assumed before the means of achieving it can
be explored
• The designers have to work backwards in time from
an assumed effect upon the world to the beginning of
a chain of events that will bring the real effect
The interaction between mankind and the
surrounding world
 The interaction between mankind and the
surrounding world
• The interaction between mankind and the
surrounding world has historically taken
two paths.
• The path of science has been concerned
with studying things as they are with
observation and experimentation as its
key activities.
• The path of engineering concerned
creating new things with construction and
evaluation as its key activities.
The Nature Of Scientific Analysis
Model of the design process
 Black box testing
• Black box also known as Behavioural Testing,
in which the “ internal structure/ design/
implementation” of the item being tested is
not known to the tester.

• Black box is named so because in the eyes of

the tester it looks like a black box
 Black box
EXAMPLE
A tester, without knowledge of the internal
structures of a website, tests the web pages
by using a browser; providing inputs (clicks,
keystrokes) and verifying the outputs against
the expected outcome.
White box
• White Box Testing known as Clear Box
Testing, Open Box Testing, Glass Box
Testing, Transparent Box Testing, Code-
Based Testing or Structural Testing.
• In which the internal structure/ design/
implementation of the item being tested is
known to the tester.
Difference between Black box and White box
 Set of actions involved in design
• The set of actions can be summarized as
– Assume a solution;
– Build a model of the solution;
– Evaluate the model against the original
requirement;
– Elaborate the model to produce a detailed
specification of the solution.

• It is usually necessary to perform many iterations

between the different stages of the design process, as
well as extensive backtracking that may be needed for
the revision of design choices.
 An Example of a Design
Process
• Moving house problem
• Garden shed problem
– Refer pages from 25-29 from the text book
The role of the design activity
• The principal task for the designer is to
specify the best solution to a problem and
produce a description of how this is to be
organized.
• This description then forms a ‘plan’ that
can be used by the eventual implementers
of the system.
 How a designer learns?
• Apprenticeship
• Design studio
• Sketchbooks
• Engineer’s commonplace book
• knowledge gained from scientific research
• the concept of reuse
• the idea of ‘standardizing’ components
 Design activity
• The form of the output produced from the
design process depends not only upon the
nature of the problem, but also upon the nature
of its implementation.
• The plans produced by the designer may need
to indicate some information about the
sequencing of operations in the construction
process.
• Communication with those responsible for
fabricating the solution is an important part of
the designer’s role, especially for larger-scale
developments.
 Input to the design process
• ‘requirements’ specification
• ‘domain knowledge’
• The main task of the design phase is to
produce the plans necessary for software
production to proceed.
 Designer’s plan
• The static structure of the system
• Any data objects to be used in the system
• The algorithms to be used
• The packaging of the system, in terms of how
components are grouped in compilation units
• Interactions between components
• The strategy for their eventual integration into
the complete system.
 Software design
• Designing software consists of designing
a process-development
• It becomes necessary to model and
describe its behavior as well as its
structure, and also the functions that it
will perform.
• The dynamic nature of a software system
influences (and complicates) the process
of design
 Software design view points
• Designing software consists of designing a
process and it describe its behavior,
structure and functions that it will
perform.
• To help with constructing the model ,each
representation providing a different
viewpoint on the form of a design
• Below figure shows view points structure
Design as a problem-solving process
• The purpose of design is simply to
produce a solution to a problem.
• It is the designer’s task to provide a
description of how that requirement is to
be met.
• The basic two needs of design are that it
should work and that it should do the
required job as well as possible
 Design as a problem-solving
process
• Representations can also help with the
process of building models of the
intended system and with evaluating its
behavior.
• Abstraction is concerned with the
removal of detail from a description of a
problem.
• Ex: moving house problem.
 Abstraction in design
• The designer needs to learn to think about a system in an
abstract way – in terms of events, entities, objects, or whatever
other key items are appropriate.
• The effective use of abstraction is a key skill that any designer
needs to learn and practice.
 Design as a wicked(good)
problem – July 24th
• Design leads to a single preferred
solution
• Solution sometimes changes the
problem.
• By Adding one feature may be require
huge redesign of internal data structures
and re-organization of subprograms.
 The properties of a wicked problem
– by Rittel Weber
• There are some wicked problems identified
1. There is no definitive formulation of a wicked problem
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true or false but
good or bad
4. There is no immediate and no ultimate test of a solution to
a wicked problem.
5. Every solution to a wicked problem is a ‘one-shot
operation’, because there is no opportunity to learn by
trial-and-error, every attempt counts significantly.
Ex: collecting tax and paying pension
6. Wicked problems do not have an enumerable (or an
exhaustively describable) set of potential solutions.
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered to be a symptom
of another problem.
 Chap- 2 “The Software Design
Processes”
Content
- Building models
- Transferring design knowledge
- Constraints upon the design process
 Chap – 2 “Building models”
Factors affecting software development.
Complexity: complexity is arbitrary (subjective),
being dependent upon the designer rather than the
problem.
Conformity: Software, being ‘pliable’ (flexible), is
expected to conform to the standards imposed by
other components.
Changeability: Software suffers constant need for
change.
Invisibility:
• software is ‘invisible’, any forms of
representation that are used to describe it will lack
any form of visual link.
 Software model
• Models used to predict the behavior of a
system within a given context or scenario.
• Constructing a model for a proposed solution
allows the designer to assess its behavior and
structure.
A general model of the software design
process
 Process of design in larger
systems
• First phase : Develop
abstract model of a
solution (black box
partitioning of the
problem).
• Second phase: the abstract
can be again divide into
chunks(portions) of the
problem from phase I.
i.e. turning black box into
a white box.
 Research findings on software
design process
• Architectural model – highly abstract in nature
• Abstract model simulates the dynamic behavior of
the system
• Keeping all elements of the design at the same level
as they are developed
• Making the constraints explicit
• Reuse of previous design plans
• Creating documents for future systematic expansion
of the design.
 Transferring design knowledge
• 3 significant characteristics of an
exceptional designer:
– Familiarity with the application
domain
– Skill in communicating technical vision
to other project members.
– Identification with project performance
The characteristics of an exceptional
designer
 Software Design Method

Heuristics
Guidelines for the design method
Constraints upon the design process
• In the example of “moving house”, the constraints
were concerned both with functional issues (blocking
power outlets or windows) and with aesthetic ones
(clashes of style or color, or putting a bed in the
dining room etc.).
• These considerations largely act to constrain the form
of the solution (or product in this case).
• For the example of designing garden sheds, the main
constraints were again on the form of the product, and
were driven by the need to provide a way of
constructing sheds from easily prefabricated units.
 Constraints upon the design process
• Determined by the eventual run-time
environment (organization of file structures).
• The need to conform to the conventions
required by a chosen architectural style
• Reusing existing software components, this
may lead to further constraints upon the
‘acceptable’ architectural styles
• select the major software facilities (operating
system, programming language)
• The use of imperative forms (bossy) is not
essential to the design process
• Concerned with designer skills and
knowledge (experience with a particular
method)
• Constraints will be identified in the initial
specification documents

• Some constraints are problem-specific (such as

the level of user skills that should be assumed
for a new application)

• Others are more solution-specific (such as

architectural style)
 DESIGN QUALITIES
Content
1.The quality concept
2.Assessing design quality
- A framework for assessment
- The ilities
- Cognitive dimensions
•Quality attributes of the design product
•Assessing the design process
 The Quality Concept
• In order to achieve high standards of
quality in design products, one needs to
seek high standards of quality in the
design process.
• The idea of quality as applied to software
is at least partly problem-related in
nature, so it is certainly not guaranteed by
the use of some particular form for the
design process.
 Assessing Design Quality
• ‘When you can measure what you are speaking
about, and express it in numbers, you know
something about it, but when you cannot
measure it, when you cannot express it in
numbers, your knowledge is of a meagre and
unsatisfactory kind.’(Lord Kelvin.)

• Fenton and Pfleeger (1997) have observed

that ‘measurement is concerned with capturing
information about attributes of entities’, so at
this point it is useful to identify more carefully
how our ideas about quality can be tied to
ideas about measurement.
 2.1 A framework for assessment
• Quality concepts are the abstract ideas that we have
about what constitutes ‘good’ and ‘bad’ properties of
a system, and which will need to be assessed by the
designer when making decisions about design
choices.
• Design attributes provide a set of measurable (or at
least, identifiable) characteristics of the design
entities and so provide mappings between the abstract
idea of a property and the countable features of an
actual design
• Counts are concerned with realizing the design
attributes, and so involve identifying the
lexical(function) features of a representation that will
need to be counted in order to obtain some form of
values for the metrics.
The below figure shows the initial mapping by Fuller
Quality concepts in 3 levels
 The ‘ilities’
Reliability :To check whether the system is
1. Complete
2. Consistent
3. Robust
Efficiency : The efficiency of a system can be
measured through its use of resources such as
processor time, memory, network access, system
facilities, disk space and so on.
Maintainability : As systems get larger and more
costly, by ensuring a long lifetime in service
increases in parallel.
Usability : The design of the user interface
(usually termed the Human–Computer
Interaction, or HCI) will form an important
component.
2.3 Cognitive(reasoning) dimensions
The Requirements for Good Design
 Design Viewpoints for Software
• In order to formulate and explore the design
model, a designer needs to use a set of description
forms that are able to describe both the static and
the dynamic properties of a system.
• In order to describe system-oriented properties,
the designer usually needs forms that describe the
dynamic behavior of the system.
• For more detailed solution-oriented design needs,
which are often concerned with describing
‘constructional’ issues such as packaging,
procedure hierarchy, and data organization, the
chosen forms will generally focus on static design
attributes.
 Representing Abstract Ideas
• A representation is the means that to capture certain
properties of a design and not to be regarded as
design itself.
• This concept of the viewpoint as design model which
is shown below
Evolution of the overall design model
 Design representations
Constructional forms - In which the
viewpoint is concerned with essentially static
aspects of the system
Behavioral forms - a set of viewpoints that
seek to describe the causal links between
events and system responses during
execution
Functional forms - viewpoints that seek to
describe what the system does in terms of its
tasks
Data-modelling forms - concerned with the
data objects used within the system, and the
relationships between these.
 Design representations – conti..
• The representations can all be classified
as ‘direct’ viewpoints, in that they are
created directly by the designer.
• A further class of viewpoints can be
described as ‘derived’ viewpoints
(Budgen and Friel, 1992), in which some
transformation is applied to the design
model in order to generate a ‘new’
representation form.
The use of derived viewpoints
 Constructional forms
•Data specification: The data in files, header files,
HTML,XML.
•Threads of execution: subprogram organization,
threads
•Packaging constructs: Ex: Java class, Ada package
• The relationships and dependencies that will exist
between the elements of the system. They are
 Data flow- It related to the sources and forms of data
 Invocation – Describing how the flow of control is
managed between program element
 User hierarchy- Describing the dependencies that
exist between classes.
 Behavioral forms
• Connecting an ‘event’ to a ‘response’ via any
necessary conditions.
• Concerned with operations that may actually
be spread across a number of the physical
elements in a system.
• Most of these forms can be considered as
examples of finite-state machines
• Required to handle some of the design
properties that are concerned with time.
 Behavioral forms
Examples of time They are
• Sequencing
• Fixed – interval
• Constraint
• Behavioral descriptions can be used for both
black box modeling roles and white box
modelling.
 Functional forms
Functional forms
• What a system does?
• Problem-driven
• To describe the runtime behavior of
program elements
Data-modelling forms
• The viewpoints describes data structures
• static in nature
 Design Practices
Design Attributes:
1.Simplicity

2.Modularity

3.Information-hiding
 Design Practices
1.Simplicity
• Characteristic of almost all good designs, of
activity they are produced is a basic simplicity

• “a solution should be as simple as possible”,

but no simpler.

• One important aid to achieving simplification

is abstraction.
 Design Practices
Modularity:
• The use of an appropriate form of
modular structuring for a given problem
is to make possible smaller components.
• It Not only related to s/w but also
engineering design
• To make good use of a modular structure,
one needs to adopt a design practice
based on a separation of concerns.
 Design Practices
Modularity:
• Simplify defining interfaces is not enough; a
designer needs to group functions within
modules in such a way that their
interdependence is minimized.
• A grouping results in a less complex interface
to the module;
• In the case of hardware, it may simply be that
fewer interconnections are required;
• For software, we need to find other criteria in
order to measure this factor.
 Design Practices
Modularity Benefits:
• Modules are easy to replace
• Each module captures one feature of
problem, so aiding comprehension ( and
hence maintenance), as well as providing
a framework for designing as a team;
• A well-structured modules can easily be
reused for another problem
• In terms of the design properties, modularity
should be related to such quality concepts as
maintainability, testability and (possibly) to
usability and reliability too.
 Design Practices
Types of modularity
•There are 2 quality measure to assess
Modularity.
1.Coupling
2.Cohesion
Coupling: It is a measure of inter- modal
connectivity, and is concerned with
identifying the forms of connection that
exist between modules and the strength of
these connection.
 Design Practices
Forms of module coupling
 Design Practices
Cohesion: It provides a measure of the
extent to which the components of a
module can be considered to be
‘functionally related’.
 Design Practices
The principal forms of cohesion
Difference between of Cohesion and
coupling
Coupling model
Cohesion Model
 Information Hiding
• It related to modularity and incorporates
additional notions about managing
information in a system.
• It encourages the designer to keep
information about the detailed forms of
such objects as data structures and device
interfaces local to a module, or a unit, and
to ensure that such information should
not be made ‘visible’ outside that
unit(Parnas,1972).