Software Design

Design

- a plan or specification for the: Initial

• construction of an object or system for 1. Conduct
Observations
More Systematic
the implementation of an activity. Experiment
Observations
s
• process or the result of that plan or
specification in the form of a prototype, 2. Construct Theory
(model)
product, or process. Predictions
• human characteristic: Making of, and from Theory
3. Devise Experiments
the use of tools. to Test Theory Experimental
Observations
• producing any form of artifact is an act
that implicitly incorporates some 4. Refine the Theory

element of design activity, whether or

not this is explicitly appreciated at the 5. Derive Scientific
New Predictions

time. Principles Experimental

Observations
Artifacts

- a byproduct of software development that

helps describe the architecture, design and
External
function of software. Requirements
1. Clarify Nature
- are like roadmaps that software developers can Requirements
of Requirements Specification
use to trace the entire software development
process. 2. Analyse Needs and
- might be databases, data models, printed Build ‘Black Box’ Functional
documents or scripts. Model of Problem Specification
Functional
3. Postulate a ‘White
Specification
Box’ Design Solution

4. Validate Solution List of Mismatches

(including use of
prototypes)
White Box Model
5. Implementation of
the Design Plan
Using a Suitable Design Plan
Form of Software

The Role of the Design Activity

Communication
- the principal task for the designer is to specify
- distinguishing characteristic of human beings. the best solution to a problem and produce a
- translating a ‘design’ into a ‘product’ almost description of how this is to be organized.
always involves communicating the designer’s
ideas to the development team.

Products of Some Design Process

Requirements
- various artifacts that are the outcome of many Specification
different applications of the design process
extensively influence our lives.
- devised and created by human beings.

Constraints
Plans for
Realization
of the Design

Domain Knowledge

Chapter 1
Software Design

Design as a Problem-Solving Process

- the purpose of design is simply to produce a

solution to a problem.
- abstraction therefore plays a key role.
- problem solving is the act of
- defining a problem; determining the cause of
the problem; identifying, prioritizing, and
selecting alternatives for a solution; and
implementing a solution.

Importance of Abstraction in Software Design

- used to hide background details or any

unnecessary implementation about the data so
that users only see the required information.
- “displays” only the relevant attributes of
objects and “hides” the unnecessary details.

Design as a ‘wicked’ Problem Software Design Concepts

- can be characterized as a problem whose form
is such that a solution for one of its aspects
simply changes the problem.
Software
- set of instructions, data or programs used to
operate computers and execute specific tasks.
- defined as a principal idea or invention that
comes into our mind or in thought to
understand something.
- simply means the idea or principle behind the
design.

Software Design

- process to transform the user requirements

into some suitable form, which helps the
programmer in software coding and
implementation.
- process of envisioning and defining software
solutions to one or more sets of problems.

The Following Items are Designed and Documented

During the Design Phase:

• different modules required.

• control relationships among modules. Software Development Problems:
• interface among different modules.
- Problem 1: Unclear and Ever-Changing
• data structure among the different modules.
Software Requirements
• algorithms required to implement among the
- Problem 2: Inadequate Communication
individual modules.
- Problem 3: Confidentiality of Information
Objectives of Software Design: - Problem 4: Too Many Bugs and A Flawed
Final Product
• Correctness - Problem 5: Hidden Costs
• Efficiency
• Understandability
• Completeness
• Maintainability

Chapter 1
Software Design

Software Analysis and Design • Data Flow - Movement of data is

shown by pointed arrows. Data
- includes all activities, which help the
movement is shown from the base of
transformation of requirement specification
arrow as its source towards head of the
into implementation.
arrow as destination.
- the intermediate stage, which helps human-
readable requirements to be transformed into Levels of DFD
actual code.
- Level 0 - highest abstraction level DFD is
Requirement Specification known as Level 0 DFD, which depicts the
entire information system as one diagram
- specify all functional and non-functional
concealing all the underlying details. Level 0
expectations from the software.
DFDs are also known as context level DFDs.
- come in the shape of human readable and
understandable documents, to which a
computer has nothing to do.

Data Flow Diagram

- graphical representation of flow of data in an

information system.
- capable of depicting incoming data flow,
outgoing data flow and stored data.
- DFD does not mention anything about how
data flows through the system.

Difference of DFD and Flowchart
- flowchart depicts flow of control in program
modules; while
- DFDs depict flow of data in the system at
various levels. DFD does not contain any
control or branch elements.
- Level 1 - the Level 0 DFD is broken down into
more specific, Level 1 DFD. Level 1 DFD
depicts basic modules in the system and flow
of data among various modules. Level 1 DFD
also mentions basic processes and sources of
information.

Types of DFD

• Logical DFD - concentrates on the system

process, and flow of data in the system. For
example, in a Banking software system, how
data is moved between different entities.
• Physical DFD - shows how the data flow is
actually implemented in the system. It is more
specific and closer to the implementation.

DFD Components

- can represent source, destination, storage and
flow of data using the following set of
components:
- Level 2 - at this level, DFD shows how data
flows inside the modules mentioned in Level 1.
Higher level DFDs can be transformed into
more specific lower level DFDs with deeper
level of understanding unless the desired level
of specification is achieved.

Structure Charts
• Entities – source and destination of
- chart derived from DFD.
information data. Entities are
- represents the system in more detail than DFD.
represented by a rectangle with their
- breaks down the entire system into lowest
respective names.
functional modules, describes functions and
• Process - activities and action taken on
sub-functions of each module of the system to
the data are represented by circle or
a greater detail than DFD.
round-edged rectangles.
- represents hierarchical structure of modules.
• Data Storage - There are two variants
At each layer a specific task is performed.
of data storage - it can either be
represented as a rectangle with
absence of both smaller sides or as an
open-sided rectangle with only one
side missing.

Chapter 2
Software Design
symbols used in construction of structure charts:
• Module - represents process or subroutine
or task. A control module branches to more
than one sub-module. Library Modules are
re-usable and invokable from any module.
• Condition - represented by small diamond
at the base of module. It depicts that
control module can select any of sub-
routine based on some condition.
• Jump – an arrow is shown pointing inside
the module to depict that the control will
jump in the middle of the sub-module.
• Loop - a curved arrow represents loop in
the module. All sub-modules covered by
loop repeat execution of module.
• Data Flow - a directed arrow with empty
circle at the end represents data flow.
• Control Flow - a directed arrow with filled
circle at the end represents control flow.
HIPO Diagram
- Hierarchical Input Process Output diagram is
a combination of two organized method to
analyze the system and provide the means of
documentation.
- HIPO model was developed by IBM in year
1970.
- represents the hierarchy of modules in the
software system.
- Analyst uses HIPO diagram in order to obtain
high-level view of system functions.
- decomposes functions into sub-functions in a
hierarchical manner. It depicts the functions
performed by system.
- good for documentation purpose. Their
graphical representation makes it easier for
designers and managers to get the pictorial
idea of the system structure.
- in contrast to IPO (Input Process Output)
diagram, which depicts the flow of control and
data in a module, HIPO does not provide any
information about data flow or control flow.
- both parts of HIPO diagram, Hierarchical
presentation and IPO Chart are used for
structure design of software program as well
as documentation of the same.
Chapter 2
Software Design

Structured English

- most programmers are unaware of the large

picture of software so they only rely on what
their managers tell them to do.
- It is the responsibility of higher software
management to provide accurate information
to the programmers to develop accurate yet
fast code.
- Hence, analysts and designers of the software
come up with tools such as Structured English.
It is nothing but the description of what is
required to code and how to code it.
Decision Tables
- Structured English helps the programmer to
write error-free code. - represents conditions and the respective
- Other form of methods, which use graphs or actions to be taken to address them, in a
diagrams, may are sometimes interpreted structured tabular format.
differently by different people. Here, both - powerful tool to debug and prevent errors.
Structured English and Pseudo-Code tries to - helps group similar information into a single
mitigate that understanding gap. table and then by combining tables it delivers
- Structured English is the It uses plain English easy and convenient decision-making.
words in structured programming paradigm.
Creating Decision Table
It is not the ultimate code but a kind of
description what is required to code and how - to create the decision table, the developer must
to code it. The following are some tokens of follow basic four steps:
structured programming. • Identify all possible conditions to be
addressed;
• Determine actions for all identified
conditions;
- Analyst uses the same variable and data name,
• Create Maximum possible rules; and
which are stored in Data Dictionary, making it
• Define action for each rule
much simpler to write and understand the
- should be verified by end-users and can lately
code.
be simplified by eliminating duplicate rules
• Example: We take the same example of
and actions.
Customer Authentication in the online
shopping environment. This
procedure to authenticate customer
can be written in Structured English as:

- The code written in Structured English is more

like day-to-day spoken English. It cannot be
implemented directly as a code of software.
Structured English is independent of
programming language.

Pseudo-Code
Entity-Relationship Model
- written closer to programming language.
- type of database model based on the notion of
- may be considered as augmented
real-world entities and relationship among
programming language, full of comments and
them. We can map real world scenario onto ER
descriptions.
database model.
- avoids variable declaration but they are
- creates a set of entities with their attributes, a
written using some actual programming
set of constraints and relation among them.
language’s constructs, like C, Fortran, Pascal
- ER Model is best used for the conceptual
etc.
design of database. ER Model can be
- contains more programming details than
represented as follows:
Structured English.
- provides a method to perform the task, as if a
computer is executing the code.

Chapter 2
Software Design

- Data Flow is described by means of DFDs as

studied earlier and represented in algebraic
form as described.

• Entity - an entity in ER Model is a real

world being, which has some
properties called attributes. Every
attribute is defined by its
corresponding set of values, called
domain. For example, Consider a
school database. Here, a student is an Data Elements
entity. Student has various attributes
like name, id, age and class etc. - consist of Name and descriptions of Data and
• Relationship - the logical association Control Items, Internal or External data stores
among entities is called relationship. etc. with the following details:
Relationships are mapped with entities • Primary Name
in various ways. Mapping cardinalities • Secondary Name (Alias)
define the number of associations • Use-case (How and where to use)
between two entities. • Content Description (Notation etc.)
Mapping cardinalities: • Supplementary Information (preset
❖ one to one values, constraints etc.)
❖ one to many Data Store
❖ many to one
❖ many to many - stores the information from where the data
enters into the system and exists out of the
Data Dictionary system.
- centralized collection of information about - it may include:
data. • Files
- stores meaning and origin of data, its ❖ Internal to software.
relationship with other data, data format for ❖ External to software but on the
usage etc. same machine.
- has rigorous definitions of all names in order ❖ External to software and
to facilitate user and software designers. system, located on different
- often referenced as meta-data (data about data) machine.
repository. • Tables
- created along with DFD (Data Flow Diagram) ❖ Naming convention
model of software program and is expected to ❖ Indexing property
be updated whenever DFD is changed or Data Processing
updated.
• two types of Data Processing:
Requirement of data Dictionary • Logical: as user sees it
- data is referenced via data dictionary while • Physical: as software sees it
designing and implementing software.
- removes any chances of ambiguity.
- helps keeping work of programmers and
designers synchronized while using same
object reference everywhere in the program.
- provides a way of documentation for the
complete database system in one place.
- validation of DFD is carried out using data
dictionary.
Contents
Data dictionary should contain information
about the following:
• Data Flow
• Data Structure
• Data Elements
• Data Stores
• Data Processing

Chapter 2
Software Design

Software Process Models Iterative Models

Program Life Cycle - The best practice is to iterate and deliver

incrementally, treating each iteration as a
• Conception
closed- end “mini-project,” including complete
• Requirements
requirements, design, coding, integration,
gathering/exploration/modeling
testing, and internal delivery. On the iteration
• Design
deadline, deliver the (fully-tested, fully-
• Coding and debugging
integrated) system thus far to internal
• Testing
stakeholders. Solicit their feedback on that
• Release
work, and fold that feedback into the plan for
• Maintenance/software evolution
the next iteration.
• Retirement
• (From “How Agile Projects Succeed”)
Project Management Models
Evolving the Iterative Model
• Plan-Driven Models
- traditional way of implementing the iterative
o models have more clearly defined
model is known as evolutionary prototyping.
phases, and more requirements for
sign-off on completion of a phase.
• Agile Development Models
o the agile models are inherently
incremental and make the assumption
that small, frequent releases produce a
more robust product than larger, less
frequent ones.

The Four Variables

• Cost is probably the most constrained

• Time is your delivery schedule and is
unfortunately many times, imposed on you
from the outside.
• Quality is the number and severity of defects
you’re willing to release with.
• Features (also called scope) are what the Risk: The Problem with Plan-Driven Models
product actually does.
- the most basic problem in software.
Code and Fix Model - manifests itself in many ways: schedule slips,
- often used in lieu of actual project project cancelation, increased defect rates,
management. misunderstanding of the business problem,
false feature richness (you’ve added features
the customer really doesn’t want or need), and
staff turnover.

Agile Methodologies

- starting in the mid-1990s

- this new process model was lightweight.
- required less documentation and fewer
process controls.
Cruising Over the Waterfall
Agile Values and Principles
- it generally requires that you finish phase N
before you continue on to phase N+1 - Values:
• Individuals and interactions over
Conceptual Development
processes and tools
Requirement • Working software over comprehensive
Analysis
documentation
Architectural Design
• Customer collaboration over contract
Detailed Design negotiation
• Responding to change over following a
Code and Debug
plan
System Testing
Release and
Maintenance

Chapter 3
Software Design
- Principles:
• Our highest priority is to satisfy the
customer through early and
continuous delivery of valuable
software.
• Welcome changing requirements, even
late in development. Agile processes
harness change for the customer’s
competitive advantage.
• Deliver working software frequently,
from a couple of weeks to a couple of
months, with a preference to the
shorter timescale.
• Business people and developers must
work together daily throughout the
project.
• Build projects around motivated
individuals. Give them the
environment and support they need,
and trust them to get the job done.
• The most efficient and effective
method of conveying information to
and within a development team is face-
to-face conversation.
• Working software is the primary way
to measure progress.
• Agile processes promote sustainable
development. The sponsors,
developers, and users should be able to
maintain a constant pace indefinitely.
• Continuous attention to technical
excellence and good design enhances
agility.
• Simplicity—the art of maximizing the
amount of work not done —is
essential.
• The best architectures, requirements,
and designs emerge from self-
organizing teams.
• At regular intervals, the team reflects
on how to become more effective and
then tunes and adjusts its behavior
accordingly.
eXtreme Programing (XP)
- Kent Beck and Ward Cunningham created XP
around 1995.
- a “lightweight, efficient, low-risk, flexible,
predictable, scientific, and fun way to develop
software.”11
XP Overview
- XP relies on the following four fundamental
ideas:
• Heavy Customer Involvement: XP
requires that a customer representative
be part of the development team and
be on site at all times.
• Continuous Unit Testing (also known
as Test-Driven Development, or TDD):
XP calls for developers to write the unit
tests for any new features before any of
the code is written.
• Pair Programming: XP requires that
pairs of developers write all code. In a
nutshell, pair programming requires
two programmers—a driver and a
navigator—who share a single
computer.
• Short Iteration Cycles and Frequent
Releases: XP typically uses release
cycles in the range of just a few weeks
or months, and each release is
composed of several iterations, each on
the order of three to five weeks.
Four Basic Activities:
- XP describes four activities that are the
bedrock of the discipline:
• Designing: Design while you code.
• Coding: The code is where the
knowledge of the system resides, so it’s
your main activity.
• Testing: The tests tell you when you’re
done coding.
• Listening: To your partner and to the
customer.
Implementing XP: The 12 Practices
1. The Planning Game - develop the scope of the
next release by combining business priorities
and technical estimates.
2. Small Releases - put a simple system into
production quickly and then release new
versions on a very short cycle.
3. Metaphor - “A simple shared story of how the
whole system works.” The metaphor replaces
your architecture.
4. Simple Design - keep the design as simple as
you can each day and re-design often to keep it
simple.
5. Testing - programmers constantly write unit
tests. Tests must all pass before integration.
6. Refactoring - restructure the system “without
changing its behavior” to make it simpler—
removing redundancy, eliminating
unnecessary layers of code, or adding
flexibility.
7. Pair Programming - two programmers at one
machine must write all production code in an
XP project.
8. Collective Ownership - the team owns
everything, implying that anyone can change
anything at any time.
9. Continuous Integration - integrate and build
every time a task is finished, possibly several
times a day (as long as the tests all pass).
10. 40-hour Week - work a regular 40-hour week.
Never work a second week in a row with
overtime.
Chapter 3
Software Design

11. On-Site Customer - customer is part of the Lean Software Development

team, is on-site, writes and executes functional
- comes from the just-in-time manufacturing
tests, and helps clarify requirements.
processes (also known as the Toyota
12. Coding Standards - the team has them, follows
Production System, among other names)
them, and uses them to improve
- were introduced in Japan in the 1970s and then
communication.
made their way around the world in the 1980s
Scrum and 1990s
- encouraged by the publication in 1990 of The
- second agile methodology.
Machine That Changed The World by
- means of restarting play after a rule’s
Womack, et. al.1
infraction.
Seven Key Principles for Software Development:
Scrum Roles
1. Eliminate Waste - eliminate anything that
- requirements normally take the form of user
doesn’t add value to the product.
stories—features that can be summarized by
2. Build Quality In - quality issues are the bane
sentences like
of every software developer.
• “As a <type of user>,
3. Create Knowledge - the team must learn new
• I want to <do or create something>,
things constantly.
• so that <some value is created>.
4. Defer Commitment - put off decisions
- defines three roles in a development project:
(particularly irreversible ones) as long as you
• Product Owner - the person who
can and only make them when you must.
generates the requirements for the
5. Deliver Fast - “First to market”
product and prioritizes them.
6. Respect People - all about building strong,
• Scrum Master - whose job it is to
productive teams.
manage the backlogs, run the daily
7. Optimize the Whole - keep the entire product
Scrum meetings, coach the team, and
picture in sight as you develop.
protect the team from outside
influences during the sprint. Kanban
• Development Team - itself is self-
- Kanban method is a practice derived from lean
organizing; the members of the Scrum
manufacturing (the Toyota Production
team decide among themselves who
System) and other change-management
will work on what user stories and
systems; it draws most of its original ideas
tasks, assume collective ownership of
from the just-in-time manufacturing processes.
the project, and decide on the
- uses three ideas to influence a development
development process they’ll use
process:
during the sprint.
• Work-in-Progress - the total number of
Sprint tasks the team is currently working on.
• Flow - the passage of tasks from one
- scrum is characterized by the sprint, an
state to another on the way to
iteration of between one and four weeks.
completion.
Scrum Artifacts • Lead Time - the amount of time it takes
a task to move from its initial state to
- Scrum requirements are encapsulated in two its completed state.
backlogs:
• Product Backlog - the prioritized list of The Kanban Board, WIP, and Flow
all the requirements for the project; the
- These boards are often physical white boards
product owner creates it.
that occupy one wall of a common space for the
• Sprint Backlog - the prioritized list of
team.
user stories for the current sprint.

Sprint Flow

- Before the first sprint starts, Scrum has an

initial planning phase that creates the product
list of the initial requirements, decides on an
architecture for implementing the
requirements, divides the user stories into
prioritized groups for the sprints, and breaks
the first set of user stories into tasks to be
estimated and assigned.

Chapter 3
Software Design

A Task/Kanban Board Applied to a Software

Development Project

Kanban Software

Summary

- iteration is the key, whether you’re using an

evolutionary, plan-driven process or an agile
development one.
- recognize that the best way to build a complex
piece of software is incrementally.
- learn that designing, writing, testing, and
delivering incrementally better code is your
first step to writing great software.

Chapter 3
Software Design
Project Management Essentials
Project Management
- an involved and complicated set of tasks.
- several tasks that will impact you as a
developer the most:
• Project planning
• Estimation and scheduling
• Resource management
• Project oversight
• Project reviews and presentations
• The project retrospective
Project Planning
- project planning is forever.
- generally, a project plan consists of the
following seven parts:
1. Introduction and explanation of the
project
2. Team organization
3. Risk analysis
4. Hardware, software, and human
resource requirements
5. Task list and size and effort estimates
6. Project schedule
7. Project monitoring and reporting
mechanisms, collectively known as
project oversight
Agile Project Plan
- feature-based (remember it’s built around
getting production code running quickly).
- organized into iterations.
- multi-layered (because it knows that things
will change and that the initial set of
requirements are not complete or detailed
enough).
- owned by the team, not the project manager.
Project Organization
- project organization section of the plan
contains the following three things:
• How you’re going to organize the team
• What process model the project will be
using
• How will the project be run on a day-
to-day basis
Risk Analysis
- in the risk analysis section, you need to think
about the bad things.
Some Risks to Watch Out for Include the Following:
• Schedule Slips - that task that you estimated
would take three days has just taken three
weeks.
• Defect Rate is Excessive - your testing is
finding lots of bugs.
• Requirements Misunderstood - what you’re
doing isn’t what the customer wanted.
• Requirements Churn - probably the largest
single reason for missed delivery dates, high
defect rates, and project failure.
• Turnover - your most experienced developer
decides to join a startup three weeks before
product delivery.
Resource Requirements
- How many people do you need for the project?
Take Estimates
- the first step toward a project schedule is
seeing what you’ll be doing and figuring out
how long each step will take.
Project Schedule
- Once you have estimates of the tasks in your
first release or iteration and have people
resource estimates, you can create a schedule.
• Get your developers to tell you the
dependencies between tasks.
• Figure out what your duty cycle is.
• Take weekends, vacations, sick days,
training, and slack into account when
you’re making the schedule.
• You can’t schedule a developer to work
on two tasks at the same time.
Project Oversight
- project oversight is what happens once you’ve
got a schedule and your project is underway.
Status Reviews and Presentations
- an inescapable part of any project. The bigger
the project, the more formal the review.
Defects
- inevitably, you’ll introduce defects (errors)
into your program.
- as a developer, your aim is twofold:
• Introduce as few defects as possible
into the code you write.
• Find as many of them as you can before
releasing the code.
Defect Levels
• Fatal - either this defect causes the product to
crash, or a fundamental piece of functionality
doesn’t work (for example, you can’t save files
in your new word processor).
• Severe - a major piece of functionality doesn’t
work, and there’s no workaround for it that the
user can perform (such as Cut and Paste don’t
work at all).
• Serious - a piece of functionality doesn’t work,
but there is a workaround for it that the
customer can perform (for example, the
keyboard shortcuts for Cut and Paste don’t
work, but the pull-down menus do).
Chapter 4
Software Design

• Annoying - there’s a minor defect or error in

the documentation that may annoy the user,
but doesn’t affect how the program works (say,
Paste is always spelled Patse).
• New Feature Request - this isn’t a defect, but a
request for the product to do something new
(as in, the word processor should have a
speech-to-text feature built in).

Retrospective

- as the name implies, is an opportunity to reflect

on the project just completed and answer a few
questions.
- typically, the questions will be like the
following:
• What went right? Did our process
work the way we anticipated? Did we
meet our schedule? Did we implement
all the features required by the
customer?
• What went wrong? Why did we have
so many defects? Why did we need to
work 60-hour weeks for the last month
of the project?
• What process issues came up? Did we
follow our process? If not, what parts
were problematic?
• What do we need to fix for next time?
Given the answers to the preceding
questions, what do we need to fix in
our process, work habits, or
environment for the next project?
• Who’s responsible for the fixes?
Someone has to be responsible for the
changes to our process—who is it?
(Don’t make it a manager; the
development team should own the
process).

Summary

- the most important ideas to consider are that

the developers should own the process and
management should be supportive and listen
to the developers— particularly where
schedules and estimates are concerned—and
be the buffer between the developers and the
world.
- if you can work in an organization where those
things are true, be a happy camper, because
you’ll be able to write great code.

Chapter 4