Chapter One

Introduction

1
 Discussion

Software Design vs Software Architecture

» are they the same or different? how?

» why we design a software?

2
Design in SDLC

3
 Software Design

▪ Design is a set of activities that need to be performed by the

designer in deriving and specifying a solution to a problem.

▪ There may be more than one possible solution for a given

problem
▪ The purpose of design is to produce a solution to a problem:

» The problem: requirements specification.

» The solution: your description of how the requirements are to be

met.

4
 Cont’d
The design process consists mainly 4 activities:
» Propose a solution.

» Build a model of the solution.

» Evaluate the model against original requirements.

» Elaborate the model to produce a detailed specification of the solution.

The nature of the design process

» The design process will not be implemented in a single precise
sequence.

» The design process is iterative in nature.

» The design process contains the extensive backtracking.

5
 Cont’d

Design is the creative process of describing and transforming a

problem into a solution.

Software design describe:

» The system well enough that coders can build it and deploy
it without serious problems.

» All the parts of the system and how they are to be assembled.

» Each part in detail so that it can be coded.

It consists of a set of documents (diagrams and text).

6
 Design Concepts

Design concepts provide software designer with

basic ideas from which more sophisticated design
methods can be applied.

The fundamental concepts in software design are:

» Abstraction

» Modularity

» Refinement

» Architecture
7
 Abstraction
Abstraction allows designers to focus on solving a problem without
being concerned about irrelevant lower level details.

Abstraction manages complexity by emphasizing on essential

characteristics and leaving implementation details.

8
 Cont’d
Abstraction is the selection of a set of concepts to represent a complex
whole.
Abstraction is mostly formed by reducing information content of a concept or
a physical phenomenon typically to retain information that is relevant to a
particular purpose.
Each step in the software design process is a refinement in the level of
abstraction of the software solution.
Abstraction methods in Object Oriented Programming (OOP):
– Encapsulation
– Information hiding
– Inheritance
– Polymorphism and dynamic binding
9
Cont’d

10
 Modularity
Modularity is the degree to which software can be understood by examining its
components independently of one another.
A module is a named entity that:
» Contains instructions, processing logic, and data structures.
» Can be separately compiled and stored in a library.
» Can be included in a program.
» Module segments can be used by invoking a name and some parameters.
» Modules can use other modules.
» Modules:
– Any kind of an “independent” software unit.
– Routines, subroutines (in Java: “methods”; in C:“functions”)
– Various physical units
Files (as in C, C++)
Library files (.a is the UNIX convention, DLL in Windows, JAR in Java)

11
 Cont’d
Partitioning a problem in to sub parts (Modules)

Quality attributes:
» Well-defined: Modules are clearly distinguished.

» Separation of concerns: each module has one concern, with minimal

overlap between modules.

» Loosely coupled.

» Cohesive.

• Cohesion is a measure of the relative functional strength of a module.

• Coupling is a measure of the relative interdependence among modules.

12
 Coupling: Degree of dependence among
components

No dependencies Loosely coupled-some dependencies

High coupling makes modifying parts

of the system difficult, e.g., modifying
a component affects all the
Highly coupled-many dependencies
components to which the component
is connected.

13
Range of Coupling

High Coupling
Content

Common

Control

Stamp Loose
Data

Uncoupled

Low 14
 Cohesion

The degree to which all elements of a component are

directed towards a single task and all elements directed
towards that task are contained in a single component.
Internal glue with which component is constructed.
All elements of component are directed toward and
essential for performing the same task.
High is good.

15
Range of Cohesion

High Cohesion
Functional
Informational

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental Low
16
 Examples of Cohesion-1

Function A Function A Time t0

Function Function
B C Function A’ Time t0 + X
logic
Function Function Time t0 + 2X
D E Function A’’

Coincidental Logical Temporal

Parts unrelated Similar functions Related by time

Function A

Function B

Function C

Procedural
Related by order of functions
17
 Examples of Cohesion-2

Function A Function A

Function B Function B

Function C Function C

Communicational Sequential
Access same data Output of one is input to
another
Function A part 1

Function A part 2

Function A part 3

Functional
Sequential with complete, related functions 18
 Individual Assignment

Review all the types of Coupling and Cohesion mentioned in

the previous slides.

Prepare a report from 3-4 pages.

The report should be hand written.

Due date: will be discussed in class

19
 Cont’d
A good architecture:
» Minimizes coupling between modules:
• Goal: modules don’t need to know much about one another to
interact.
• Low coupling makes future change easier.
» Maximizes the cohesion of each module:
• Goal: the contents of each module are strongly inter-related
• High cohesion makes a module easier to understand.

20
 Cont’d
• Advantages of Modularity
» Understandability.
» Parallel development of different modules is possible.
» Quality of design since it will be easier to:
– Test
– Verify and validate
– Measure reliability
– Maintainability( It will be easier to):
Locate faults and correct them
Enhance
Reuse modules for different design work
21
 Refinement
Refinement is the process of elaboration where the designer
provides successively more detail for each design component.

It begins with a statement of function that is defined at a high

level of abstraction.
» Decompose design decision top-down to elementary level.

» Isolate design aspects that are not independent.

» Add details incrementally in each step.

» Postpone decisions relating to detailed representations.

» Continually demonstrate that each refinement step is a correct

expansion of previous steps.
22
 Cont’d

Abstraction and refinement are complementary concepts.

» Abstraction enables a designer to specify procedure and data and
yet do not focus on low-level details.

» Refinement helps the designer to reveal low-level details as design

progresses.

» Both concepts aid designers in creating a complete design model as

the design evolves.

23
 Architecture

It provides an overall structure of the software and the ways

in which that structure provides conceptual integrity for the
system.

It serves as a framework from which more detailed design

activities are conducted.

24
 Common Design Principles
Basic design principles help software designers to manage the design
process.

When these design principles are properly applied, the software engineer
creates a design that shows both external and internal quality factors.

» External Quality Factors

– These are properties of the software that can be observed by users

E.g. speed, usability, reliability, etc

» Internal Quality Factors:

– Properties of the software seen from the technical perspective

25
 Cont’d
1. Consideration of alternative approaches
» Decision on the approaches to follow must be made based on
– the requirements of the problem, the resources available to do the job, and
design concepts
2. The design should be traceable to the analysis model.
» it is necessary to have a means for tracking how requirements have been
satisfied by the design model.
3. The design should not reinvent the wheel.
» Design time should be invested in representing truly new ideas and integrating
those patterns that already exist.
4. Reduced intellectual gap between software and the problem
» The structure of the software design should (whenever possible) reflect the
structure of the problem domain.
26
 Cont’d
5. The design should exhibit uniformity and integration
» A design is uniform if it appears that one person developed the entire
thing.
6. The design should be structured to accommodate change.
» The design should allow maintainability
7. Quality assessment of the design during the development process
» A variety of design concepts and design measures are available to
assist the designer in assessing quality.
8. The design should be structured to degrade gently (perform at a lower
quality level), even when erroneous data, events, or operating
conditions are encountered.
27
 Cont’d
9. Design is not coding, coding is not design.

» Even when detailed procedural designs are created for program

components, the level of abstraction of the design model is higher
than source code.

10. The design should be reviewed to minimize conceptual (semantic)

errors.

» A design team should ensure that major conceptual elements of the

design (omissions, ambiguity, inconsistency) have been addressed
before worrying about the syntax of the design model.

28
Keep it Simple (KIS)

29
 Goals of Software Design

Correctness
Robustness
Flexibility
Reusability
Efficiency
Reliability
Usability

30
 Cont’d

Correctness
» Software design must satisfy the requirements for the
application

» The software designed must perform what it is intended to do

Robustness
» A design or implementation is robust if it is able to handle
miscellaneous and unusual conditions such as bad data, user
error, programmer error, and environmental conditions.

31
 Cont’d
Flexibility
Requirements of an application can change in many ways.
Design should be flexible to accommodate these changes.
Reusability
The trend in software is to reuse parts among applications
» Good designs are more easily modified and reused

Efficiency
» It refers to the use of available machine cycles and memory
» Efficiency conflicts with other goals of software design

Reliability
» An application is reliable if it is relatively defect free.

Usability
» An application has high usability if users find it easy to use.

32
 What is Software Architecture?

The software architecture of a program or computing system

is the structure or structures of the system, which comprise
software elements, the externally visible properties of those
elements, and the relationships among them.

The exact structures to consider and the ways to represent

them vary according to engineering goals.

33
 Cont’d

A software architecture is an abstraction of a system.

» Architecture defines elements and how they interact.
» Architecture suppresses purely local information about
elements; private details are not architectural.

Externally-visible properties of elements are

assumptions that one elements can make about
another:
» provided services, required services, performance
characteristics, fault handling, resource usage

34
 Cont’d

Every system has an architecture.

» Every system is composed of elements and there are relationships
among them.
» In the simplest case, a system is composed of a single elements, related
only to itself.

Just having an architecture is different from having an architecture

that is known to everyone:
» The architecture versus specification of the architecture

If you don’t explicitly develop an architecture, you will get one

anyway – and you might not like what you get.
35
 Cont’d
This means that box-and-line drawings alone are not architectures; but
they are just a starting point.
» You might imagine the behavior of a box labeled “database” or “executive” -- but
that’s all
» You need to add specifications and properties.

Systems have many structures (views).

» No single structure can be the architecture.
» The set of candidate structures is not fixed or prescribed: choose whatever is
useful for analysis, communication, or understanding.
» An architecture is a very complicated construct -- too complicated to be seen all at
once.
» Views are a way to manage complexity.

36
 Who Influences Software Architecture?

The software architecture of a program or computing system

is the structure or structures of the system, which comprise
software elements, the externally visible properties of those
elements, and the relationships among them.

The exact structures to consider and the ways to represent

them vary according to engineering goals.

37
Cont’d

38
Importance of Software Architecture

“If a project has not achieved a system architecture,

including its rationale, the project should not proceed to
full-scale system development. Specifying the architecture
as a deliverable enables its use throughout the
development and maintenance process.”

Barry Boehm

39
 Architecture as Communication Vehicle

Architecture provides a common frame of reference in

which competing interests may be exposed and
negotiated.
» negotiating requirements with users and other stakeholders

» keeping the customer informed of progress and cost

» implementing management decisions and allocations

40
 Architecture Constrains Implementation

An architecture defines constraints on an implementation.

» Architectures are descriptive and prescriptive
– descriptive for communication

– prescriptive for design and implementation

» Global resource allocation decisions constrain implementations of

individual components

» System tradeoffs regarding quality attributes are in the architectural

realm.

41
 Architecture Organizes the Development
Project

The architecture influences the organizational structure for

development/maintenance efforts. Examples include
» division into teams
» units for budgeting, planning
» basis of work breakdown structure
» organization of documentation
» organization of CM libraries
» basis of integration
» basis of test plans, testing
» basis of maintenance
» Incremental deployment

42
 Architecture Permits/Precludes
Achievement of Quality Attributes

For example

If you desire Examine

performance inter-component communication
modifiability component responsibilities
security inter-component communication,
specialized components (e. g., kernels)
scalability localization of resources
ability to subset inter-component usage
reusability inter-component coupling

43
 Architecture is Key to Managing Change

An architecture helps reason about and manage change.

» important since 80% of effort in systems occurs after deployment

Architecture divides all changes into three classes:

» local: modifying a single component
» non-local: modifying several components
» architectural: modifying the gross system topology, communication, and
coordination mechanisms

A “good” architecture is one in which the most likely changes are

also the easiest to make.

44
 Architecture is Basis for Incremental
Development

An architecture helps with evolutionary prototyping and

incremental delivery.
» Architecture serves as a skeletal framework into which components
can be plugged.

» By segregating functionality into appropriate components,

experimentation is easier.

» Risky elements of the system can be identified via the architecture

and mitigated with targeted prototypes.

45
 Architecture is a Reusable Model

An architecture is an abstraction: enables a one-to-many

mapping (one architecture, many systems).

Systems can be built from large, externally developed

components that are tied together via architecture.

Architecture is the basis for product (system) commonality.

Entire software product lines can share a single

architecture.

46
 Architecture vs Design
All architecture is design.

NOT all design is architecture.

Architect draws the boundary between architectural and non-

architectural design.

SOFTWARE
DESIGN

SOFTWARE
ARCHITECTURE

47
 Summary: Software Architecture

Represents the structure of the software.

Expressed using certain views.

Includes principles behind the design and evolution of the

software.

Essential characteristics of architecture:

» High level view

» Realize ALL the use case scenarios

» Present a systemic view to all stakeholders

48