CHAPTER 6

SOFTWARE DESIGN
 What is design?

Design

Analysis Construction

Understand organization’s Define, organize and structure the Build a system that satisfies the
informational needs or requirements components of the final solution that requirements
serves as the blueprint for
Document the requirements in a set construction
of specification
Levels of Design

Analysis Design

Vision Document *Architectural Design

Detailed Requirements Detail Design

*General design/Conceptual design

Purpose of Design
• To refine and expand the software architecture of a system or
component to the extent that the design is sufficiently complete to
be implemented .

• During design, designers go deep into each component to define its

internal structure and behavioral capabilities, and the resulting
design leads to natural and efficient construction of software.
Software Design
• A meaningful engineering representation of something that is to be
built.
• Deriving a solution which satisfies software requirements
• An iterative process transforming requirements into a “blueprint”
for constructing the software.
System Design Principles
Design Principles
• Software design is both a process and a model.
• The design process is a sequence of steps that enable the designer
to describe all aspects of the software to be built.
• The design model is the equivalent of an architect’s plans for a
house. It begins by representing the totality of the thing to be built
(e.g., a three-dimensional rendering of the house) and slowly
refines the thing to provide guidance for constructing each detail
(e.g., the plumbing layout). Similarly, the design model that is
created for software provides a variety of different views of the
computer software.
Set of Principles for Software Design
• The design process should not suffer from “tunnel vision” (i.e. narrow
perspective).
• The design should be traceable to the analysis model .
• The design should not reinvent the wheel (i.e. creating something that already
exists).
• The design should “minimize the intellectual distance” [DAV95] between the
software and the problem as it exists in the real world (i.e. whenever possible
mimic the structure of the problem domain).
• The design should exhibit uniformity and integration (i.e. define rules of style
and format before design work begins).
Set of Principles for Software Design (cont)
• The design should be structured to accommodate change.
• The design should be assessed for quality as it is being created, not after
the fact.
• The design should be structured to degrade gently, even when aberrant
data, events, or operating conditions are encountered (i.e. accommodate
unusual circumstances).
• Design is not coding, coding is not design (i.e. level of abstraction of the
design model is higher than source code).
• The design should be reviewed to minimize conceptual (semantic) errors
(i.e. ensure design omissions, ambiguity, inconsistency have been
addressed).
Relationship between
Requirement and
Design
Relationship between Requirements and
Design
• Fundamentals of software architecture
• “The foundational software design activity that evaluates and
translates software requirements (both functional and non-
functional) into a collection of design elements that specify
structural and behavioral aspects of the major components of
the system, together with their provided quality and
interrelationships required to support the detailed design and
construction of software systems.”
The Design Process: Informal to Formal
Design
Informal Informal More
design formal Finished
design design
outline design

• The system should be described at several different levels of

abstraction
• Design takes place in overlapping stages. It is artificial to separate it
into distinct phases but some separation is usually necessary
The Design Process: Stages of Design
• Problem understanding
• Look at the problem from different angles to
discover the design requirements
• Identify one or more solutions
• Evaluate possible solutions and choose the most
appropriate depending on the designer's
experience and available resources
• Describe solution abstractions
• Use graphical, formal or other descriptive
notations to describe the components of the
design
• Repeat process for each identified
abstraction until the design is
expressed in primitive terms
The Design Process:
Phases in the Design Process
• Architectural design - Identify sub-systems
• Abstract specification - Specify sub-systems
• Interface design - Describe sub-system interfaces
• Component design - Decompose sub-systems into components
• Data structure design - Design data structures to hold problem data
• Algorithm design - Design algorithms for problem functions
Requir
ements
specifica
tion

Design acti
vities

Architectur
al Abstract Interface Component Data Algorithm
design specifica
tio design design structur
e design
n design

Softw are Data

System Interface Component Algorithm
specifica
tion structure
architectur
e specifica
tion specifica
tion specifica
tion
specification

Design pr
oducts
Software Architecture
Concepts and Standard
Architecture
Introduction
• A software design process is a set of
activities and controls that specify how
resources work together for the production
of software design artifacts.

• Two major activities of the software design

process include:
• Software Architecture
• Detailed Design
Advantages of Explicit Architecture
• Stakeholder communication: May be used as a focus of discussion
by system stakeholders.
• System analysis: Well-documented architecture enables the analysis
of whether the system can meet its non-functional requirements.
• Large-scale reuse: May be reusable across a range of systems or
entire lines of products.
Definition
• Architectural design :
• The design process for identifying the sub-systems making up a system and
the framework for sub-system control and communication.
• The output of this design process is a description of the software
architecture.
Architecture Analogy for Software
vs. House?
Architectural design decisions
Rationale on Architectural design decisions
• Architectural design is a creative process so the process differs
depending on the type of system being developed.
• Due to the creative process, the activities within the process depend
on the type of the system being developed, background and
experience of system architect, specific requirements of the
system
• During architectural design process, system architects have to make
a number of structural decisions that profoundly affect the system
and its development process -> 9 DESIGN DECISION QUESTIONS
 Architectural design decisions
Is there a generic
How will the system be What architectural styles How will the architectural
application architecture
distributed? are appropriate? design be evaluated?
that can be used?

What approach will be How should the

used to structure the
system?
? architecture be
documented?

How will the structural What architectural

What control strategy components be organization is best for
should be used? decomposed into delivering the non
subcomponents? functional requirements?
Architecture and System Characteristics
• How the system must be designed to achieve:
• Performance
• Security
• Safety
• Availability
• Maintainability
Architectural patterns styles

• Patterns are a means of representing, sharing and reusing

knowledge.
• An architectural pattern is a stylized description of good design
practice, which has been tried and tested in different
environments.
• Patterns should include information about when they are and
when the are not useful.
• Patterns may be represented using tabular and graphical
descriptions.
Model-View-Controller (MVC) pattern
• Separates presentation and interaction from the system data.
• The system is structured into three logical components that interact with
each other.
• Model component manages the system data and associated operations on
that data.
• View component defines and manages how the data is presented to the
user.
• Controller component manages user interaction (e.g., key presses, mouse
clicks, etc.) and passes these interactions to the View and the Model.
• When to use: Used when there are multiple ways to view and interact with
data. Also used when the future requirements for interaction and
presentation of data are unknown.
Model-View-Controller (MVC) pattern
2 View alerts Controller
Controller of
3 Controller updates model
particular event

4 Model alerts View that it has changed

View Model

5 View grabs Model data and updates itself

1 User interacts
with a View
Web application architecture using the
MVC pattern
Repository architecture
• Sub-systems must exchange data. This may be done in two ways:
• Shared data is held in a central database or repository and may
be accessed by all sub-systems;
• Each sub-system maintains its own database and passes data
explicitly to other sub-systems.
• When to use:
• large amounts of data are to be shared and stored for a long
time.
• In data-driven systems where the inclusion of data in the
repository triggers an action or tool
A repository architecture for an IDE
Client-server architecture
• Distributed system model which shows how data and processing
is distributed across a range of components.
• Can be implemented on a single computer.
• Set of stand-alone servers which provide specific services such as
printing, data management, etc.
• Set of clients which call on these services.
• Network which allows clients to database access servers.
• Used when data in a shared has to be accessed from a range of
locations.
A client–server architecture for a film
library
The Layered Model
• Organize a system into layers:
• Each layer provides services to the one outside it and acts as a
client to the layer inside.
• The design includes protocols that explain how each pair of
layers will interact.
• Each layer can be thought of as an abstract machine.
• Also called an abstract machine model.
• Incremental development of sub-systems in different layers.
• When a layer interface changes, only the adjacent layer is
affected.
The Layered Model
• Used when
• building new facilities on top of existing systems
• the development is spread across several teams with each team
responsibility for a layer of functionality
• there is a requirement for multi-level security
• security is a critical requirement.
• Example: layered security architecture - a system to provide file
security
The architecture of the LIBSYS system
Pipe and filter architecture
• The processing of the data in a system is organized so that each
processing component (filter) is discrete and carries out one type of
data transformation.
• The data flows (as in a pipe) from one component to another for
processing.
• May be referred to as a pipe and filter model (as in UNIX shell).
• Commonly used in data processing applications (both batch- and
transaction-based) where inputs are processed in separate stages
to generate related outputs.
• Not really suitable for interactive systems.
An example of the pipe and filter architecture
Application architectures
• Application systems are designed to meet an organisational need.
• As businesses have much in common, their application systems also
tend to have a common architecture that reflects the application
requirements.
• A generic application architecture is an architecture for a type of
software system that may be configured and adapted to create a
system that meets specific requirements.
Use of application architectures
• As a starting point for architectural design.
• As a design checklist.
• As a way of organising the work of the development team.
• As a means of assessing components for reuse.
• As a vocabulary for talking about application types.
Examples of application types
• Data processing applications
• Data driven applications that process data in batches without explicit user
intervention during the processing.
• Transaction processing applications
• Data-centred applications that process user requests and update
information in a system database.
• Event processing systems
• Applications where system actions depend on interpreting events from the
system’s environment.
• Language processing systems
• Applications where the users’ intentions are specified in a formal language
that is processed and interpreted by the system.
Application type examples
• Focus here is on transaction processing and language processing
systems.
• Transaction processing systems
• E-commerce systems;
• Reservation systems.
• Language processing systems
• Compilers;
• Command interpreters.
Transaction processing systems
• Process user requests for information from a database or requests
to update the database.
• From a user perspective a transaction is:
• Any coherent sequence of operations that satisfies a goal;
• For example - find the times of flights from London to Paris.
• Users make asynchronous requests for service which are then
processed by a transaction manager.
The structure of transaction processing
applications
The software architecture of an ATM
system
Information systems architecture
• Information systems have a generic architecture that can be
organised as a layered architecture.
• These are transaction-based systems as interaction with these
systems generally involves database transactions.
Layered information system architecture
The architecture of the Medical Health
Clinic-Patient Management System
(Example)
Web-based information systems
• Information and resource management systems are now usually
web-based systems where the user interfaces are implemented
using a web browser.
• For example, e-commerce systems are Internet-based resource
management systems that accept electronic orders for goods or
services and then arrange delivery of these goods or services to the
customer.
• In an e-commerce system, the application-specific layer includes
additional functionality supporting a ‘shopping cart’ in which users
can place a number of items in separate transactions, then pay for
them all together in a single transaction.
Server implementation
• These systems are often implemented as multi-tier client
server/architectures
• The web server is responsible for all user communications, with
the user interface implemented using a web browser;
• The application server is responsible for implementing
application-specific logic as well as information storage and
retrieval requests;
• The database server moves information to and from the
database and handles transaction management.
Language processing systems
• Accept a natural or artificial language as input and generate some
other representation of that language.
• May include an interpreter to act on the instructions in the language
that is being processed.
• Used in situations where the easiest way to solve a problem is to
describe an algorithm or describe the system data
• Meta-case tools process tool descriptions, method rules, etc and
generate tools.
The architecture of a language
processing system
Compiler components
• A lexical analyzer, which takes input language tokens and converts
them to an internal form.
• A symbol table, which holds information about the names of
entities (variables, class names, object names, etc.) used in the text
that is being translated.
• A syntax analyzer, which checks the syntax of the language being
translated.
• A syntax tree, which is an internal structure representing the
program being compiled.
Compiler components
• A semantic analyzer that uses information from the syntax tree and
the symbol table to check the semantic correctness of the input
language text.
• A code generator that ‘walks’ the syntax tree and generates
abstract machine code.
A pipe and filter compiler architecture
A repository architecture for a
language processing system
Design patterns
Design Patterns
• In software engineering, a design pattern is a general repeatable
solution to a commonly occurring problem in software design.
• A design pattern isn't a finished design that can be transformed
directly into code.
• It is a description or template for how to solve a problem that can
be used in many different situations.
Uses of Design Patterns
Design patterns can speed up the development process by providing tested, proven development
paradigms.

Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code
readability for coders and architects familiar with the patterns.

Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a
particular problem.

In addition, patterns allow developers to communicate using well-known, well understood names for
software interactions. Common design patterns can be improved over time, making them more robust
than ad-hoc designs.
Classification of Design Patterns
Using Patterns in Design
• In an object-oriented system, design patterns can be used by
applying two different mechanisms: inheritance and composition.
• Using inheritance, an existing design pattern becomes a template
for a new subclass. The attributes and operations that exist in the
pattern become part of the subclass.
• Composition is a concept that leads to aggregate objects. That is, a
problem may require objects that have complex functionality
The Design Concept: Modularity
• Structural criteria which tell us something about individual
modules and their interconnections
• cohesion: the glue that keeps a module together
• coupling: the strength of the connection between modules
The Design Concept: Cohesion
• A measure of how well a component 'fits together’
• A component should implement a single logical entity or function
• Cohesion is a desirable design component attribute as when a
change has to be made, it is localised in a single cohesive
component
The Design Concept: Coupling
• A measure of the strength of the interconnections between system
components
• Loose coupling means component changes are unlikely to affect
other components
• Shared variables or control information exchange lead to tight
coupling
• Loose coupling can be achieved by state decentralisation (as in
objects) and component communication via parameters or
message passing
The Design Concept: The Examples of
Coupling

Uncoupled -
no dependencies Loosely coupled - Tightly coupled -
some dependencies many dependencies
The Design Concept: Cohesion and
Coupling
Design Modelling
System modeling (Detailed Design)
• System modeling is the process of developing abstract models of a
system, with each model presenting a different view or perspective
of that system.
• System modeling has now come to mean representing a system
using some kind of graphical notation, which is now almost always
based on notations in the Unified Modeling Language (UML).
• System modelling helps the analyst to understand the functionality
of the system and models are used to communicate with customers.
UML diagram types
• Activity diagrams, which show the activities involved in a process
or in data processing .
• Use case diagrams, which show the interactions between a system
and its environment.
• Sequence diagrams, which show interactions between actors and
the system and between system components.
• Class diagrams, which show the object classes in the system and
the associations between these classes.
End of chapter