Chapter 1 - Introduction to Software Design

• What is design?
• The role of the design activity
• Design as a problem-solving process
• Design as a ‘wicked’ problem
• What is Software/Software Design?
• Properties of software as major factors affecting its development
• General model of the software design process
• Major phases of the software design process
What is design?
A design is a plan or
specification for the :
- construction of an
object or system for the
implementation of an
activity
- process or the result of
that plan or specification
in the form of
a prototype, product,
or process.
What is design?
• Human characteristic: Making
of, and the use of tools.

• Producing any form of artifact is

an act that implicitly incorporates
some element of design activity,
whether or not this is explicitly
appreciated at the time.
An artifact is a byproduct of software development that helps describe the architecture, design and
function of software.

Artifacts are like roadmaps that software developers can use to trace the entire software development
process. Artifacts might be databases, data models, printed documents or scripts.
Communication
• Distinguishing characteristic of
human beings

• Translating a ‘design’ into

a ‘product’ almost always
involves communicating the
designer’s ideas to the
development team
Products of some design process
• various artifacts that are the
outcome of many different
applications of the design process
extensively influence our lives.

• devised and created by

human beings.
The complementary nature of scientific and
engineering activities
The nature of scientific analysis
A model of the design process
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.
The designer’s channels of communication
Examples of design viewpoints
 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.
Why is abstraction important in software design?

Abstraction is used to hide background details or any unnecessary

implementation about the data so that users only see the required
information.

Abstraction “displays” only the relevant attributes of objects and

“hides” the unnecessary details.
Design as a ‘wicked’ problem

It can be characterized as a
problem whose form is such that a
solution for one of its aspects
simply changes the problem.
What is software?

Software is a set of
instructions, data or
programs used to
operate computers and
execute specific tasks.
What is Software Design
The process to transform the user requirements into some suitable
form, which helps the programmer in software coding and
implementation.

The process of envisioning and defining software solutions to one or

more sets of problems.
How to create software-based systems
The following items are designed and
documented during the design phase:

▪ Different modules required.

▪ Control relationships among modules.
▪ Interface among different modules.
▪ Data structure among the different modules.
▪ Algorithms required to implement among the individual modules
Objectives of Software Design:
1. Correctness

2. Efficiency

3. Understandability

4. Completeness

5. Maintainability
General model of the software design
process
Major phases of the software design process
Software Design Concepts

Concepts are defined as a

principal idea or invention that
comes into our mind or in
thought to understand
something.
The software design
concept simply means the idea
or principle behind the design.
Software Development Problems:
Problem 1: Unclear and Ever-Changing Software Requirements
Problem 2: Inadequate Communication
Problem 3: Confidentiality Of Information
Problem 4: Too Many Bugs And A Flawed Final Product
Problem 5: Hidden Costs
End of Chapter 1
Software analysis and design includes all activities, which help the transformation of
requirement specification into implementation. Requirement specifications specify all
functional and non-functional expectations from the software. These requirement
specifications come in the shape of human readable and understandable documents, to
which a computer has nothing to do.
Software analysis and design is the intermediate stage, which helps human-readable
requirements to be transformed into actual code.
Let us see few analysis and design tools used by software designers:

Data Flow Diagram

Data flow diagram is graphical representation of flow of data in an information system.
It is capable of depicting incoming data flow, outgoing data flow and stored data. The
DFD does not mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow
of control in program modules. DFDs depict flow of data in the system at various levels.
DFD does not contain any control or branch elements.

Types of DFD
Data Flow Diagrams are either Logical or Physical.

• Logical DFD - This type of 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 - This type of DFD shows how the data flow is actually
implemented in the system. It is more specific and close to the
implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set
of components -
 • Entities - Entities are source and destination of information data. Entities
are represented by a rectangles with their respective names.
• Process - Activities and action taken on the data are represented by Circle
or Round-edged rectangles.
• Data Storage - There are two variants 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.
• Data Flow - Movement of data is shown by pointed arrows. Data
movement is shown from the base of arrow as its source towards head of
the arrow as destination.
Levels of DFD
• Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which
depicts the entire information system as one diagram concealing all the
underlying details. Level 0 DFDs are also known as context level DFDs.

• 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.
 • 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
Structure chart is a chart derived from Data Flow Diagram. It represents the system in
more detail than DFD. It breaks down the entire system into lowest functional modules,
describes functions and sub-functions of each module of the system to a greater detail
than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific task
is performed.
Here are the symbols used in construction of structure charts -

• Module - It 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 - It is 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
HIPO (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.
HIPO diagram represents the hierarchy of modules in the software system. Analyst uses
HIPO diagram in order to obtain high-level view of system functions. It decomposes
functions into sub-functions in a hierarchical manner. It depicts the functions performed
by system.
HIPO diagrams are 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.

Example
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.
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.
Other forms of methods, which use graphs or diagrams, may are sometimes interpreted
differently by different people.
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.
Structured English helps the programmer to write error-free code.
Other form of methods, which use graphs or diagrams, may are sometimes interpreted
differently by different people. Here, both Structured English and Pseudo-Code tries to
mitigate that understanding gap.
Structured English is the It uses plain English words in structured programming
paradigm. It is not the ultimate code but a kind of description what is required to code
and how to code it. The following are some tokens of structured programming.

IF-THEN-ELSE,
DO-WHILE-UNTIL

Analyst uses the same variable and data name, which are stored in Data Dictionary,
making it much simpler to write and understand the code.

Example
We take the same example of Customer Authentication in the online shopping
environment. This procedure to authenticate customer can be written in Structured
English as:

Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
PRINT error message
Call procedure NEW_CUSTOMER_REQUEST()
ENDIF
The code written in Structured English is more like day-to-day spoken English. It can not
be implemented directly as a code of software. Structured English is independent of
programming language.

Pseudo-Code
Pseudo code is written more close to programming language. It may be considered as
augmented programming language, full of comments and descriptions.
Pseudo code avoids variable declaration but they are written using some actual
programming language’s constructs, like C, Fortran, Pascal etc.
Pseudo code contains more programming details than Structured English. It provides a
method to perform the task, as if a computer is executing the code.

Example
Program to print Fibonacci up to n numbers.

void function Fibonacci

Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
if a greater than b
{
Increase b by a;
Print b;
}
else if b greater than a
{
increase a by b;
print a;
}
}

Decision Tables
A Decision table represents conditions and the respective actions to be taken to address
them, in a structured tabular format.
It is a powerful tool to debug and prevent errors. It helps group similar information into
a single table and then by combining tables it delivers easy and convenient decision-
making.

Creating Decision Table

To create the decision table, the developer must follow basic four steps:

• Identify all possible conditions to be addressed

• Determine actions for all identified conditions
• Create Maximum possible rules
• Define action for each rule
Decision Tables should be verified by end-users and can lately be simplified by
eliminating duplicate rules and actions.

Example
Let us take a simple example of day-to-day problem with our Internet connectivity. We
begin by identifying all problems that can arise while starting the internet and their
respective possible solutions.
We list all possible problems under column conditions and the prospective actions
under column Actions.

Conditions/Actions Rules

Shows Connected N N N N Y Y Y Y

Conditions Ping is Working N N Y Y N N Y Y

Opens Website Y N Y N Y N Y N

Check network cable X

Check internet router X X X X

Actions Restart Web Browser X

Contact Service provider X X X X X X

Do no action
 Table : Decision Table – In-house Internet Troubleshooting

Entity-Relationship Model
Entity-Relationship model is a type of database model based on the notion of real world
entities and relationship among them. We can map real world scenario onto ER
database model. ER Model creates a set of entities with their attributes, a set of
constraints and relation among them.
ER Model is best used for the conceptual design of database. ER Model can be
represented as follows :

• 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 entity.
Student has various attributes like name, id, age and class etc.
• Relationship - The logical association among entities is
called relationship. Relationships are mapped with entities in various
ways. Mapping cardinalities define the number of associations between
two entities.
Mapping cardinalities:
o one to one
o one to many
o many to one
o many to many

Data Dictionary
Data dictionary is the centralized collection of information about data. It stores meaning
and origin of data, its relationship with other data, data format for usage etc. Data
dictionary has rigorous definitions of all names in order to facilitate user and software
designers.
Data dictionary is often referenced as meta-data (data about data) repository. It is
created along with DFD (Data Flow Diagram) model of software program and is
expected to be updated whenever DFD is changed or updated.

Requirement of Data Dictionary

The data is referenced via data dictionary while designing and implementing software.
Data dictionary removes any chances of ambiguity. It helps keeping work of
programmers and designers synchronized while using same object reference
everywhere in the program.
Data dictionary 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
Data Flow is described by means of DFDs as studied earlier and represented in algebraic
form as described.

= Composed of

{} Repetition

() Optional

+ And

[/] Or

Example
Address = House No + (Street / Area) + City + State
Course ID = Course Number + Course Name + Course Level + Course Grades
Data Elements
Data elements consist of Name and descriptions of Data and Control Items, Internal or
External data stores etc. with the following details:

• Primary Name
• Secondary Name (Alias)
• Use-case (How and where to use)
• Content Description (Notation etc. )
• Supplementary Information (preset values, constraints etc.)
Data Store
It stores the information from where the data enters into the system and exists out of
the system. The Data Store may include -

• Files
o Internal to software.
o External to software but on the same machine.
o External to software and system, located on different
machine.
• Tables
o Naming convention
o Indexing property

Data Processing
There are two types of Data Processing:

• Logical: As user sees it

• Physical: As software sees it
 Chapter 3
Software Process Models

A
Program life cycle
1. Conception
2. Requirements gathering/exploration/modeling
3. Design
4. Coding and debugging
5. Testing
6. Release
7. Maintenance/software evolution
8. Retirement

A
Project Management Models
• plan-driven models
• models have more clearly defined phases, and
more requirements for sign-off on completion of a
phase

• agile development models

• the agile models are inherently incremental and
make the assumption
that small, frequent releases produce a more robust
product than larger, less frequent ones.

A
The Four Variables
• The four variables of software development
projects are as follows:
• 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 product
actually does.

A
Code and Fix Model
• is often used in lieu of actual project
management.

The code and fix process model

A
Cruising over the Waterfall
• First, it generally
requires that you
finish phase N before
you continue on to
phase N+1

The waterfall process

model

A
Iterative Models
The best practice is to iterate and deliver
incrementally, treating each iteration as a
closed- end “mini-project,” including complete
requirements, design, coding, integration,
testing, and internal delivery. On the iteration
deadline, deliver the (fully-tested, fully-
integrated) system thus far to internal
stakeholders. Solicit their feedback on that work,
and fold that feedback into the plan for the next
iteration.
• (From “How Agile Projects Succeed”)

A
Evolving the Iterative Model
• A traditional way of
implementing the
iterative model is
known as
evolutionary
prototyping.

Evolutionary prototyping
process model

A
Risk: The Problem with Plan-Driven
Models
• Risk is the most basic problem in software.
• Risk manifests itself in many ways: schedule
slips, project cancelation, increased defect
rates, misunderstanding of the business
problem, false feature richness (you’ve added
features the customer really doesn’t want or
need), and staff turnover.

A
Agile Methodologies
• Starting in the mid 1990s,
• this new process model was lightweight.
• It required less documentation and fewer
process controls.

A
Agile Values and Principles
• The values are as follows
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

A
Agile Values and Principles
• The principles run as follows:

1. Our highest priority is to satisfy the customer through early

and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer’s
competitive advantage.
3. Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter
timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get
the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.

A
Agile Values and Principles
7. Working software is the primary way to measure
progress.
8. Agile processes promote sustainable development.
The sponsors, developers,
9. and users should be able to maintain a constant pace
indefinitely.
10. Continuous attention to technical excellence and good
design enhances agility.
11. Simplicity—the art of maximizing the amount of work
not done—is essential.
12. The best architectures, requirements, and designs
emerge from self-organizing
13. teams.
14. At regular intervals, the team reflects on how to
become more effective and then tunes and adjusts its
behavior accordingly.

A
eXtreme Programming (XP)
• Kent Beck and Ward Cunningham created XP
around 1995.
• XP is a “lightweight, efficient, low-risk, flexible,
predictable, scientific, and fun way to develop
software.”11

A
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.

A
The 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.

A
Implementing XP: The 12 Practices
• The planning game: Develop the scope of the
next release by combining business priorities
and technical estimates.
• Small releases: Put a simple system into
production quickly and then release new
versions on a very short cycle.
• Metaphor: “A simple shared story of how the
whole system works.” The metaphor replaces
your architecture.
• Simple design: Keep the design as simple as
you can each day and re-design often to keep
it simple.

A
Implementing XP: The 12 Practices
• Testing: Programmers constantly write unit tests.
Tests must all pass before integration.
• Refactoring: Restructure the system “without
changing its behavior” to make it simpler—
removing redundancy, eliminating unnecessary
layers of code, or adding flexibility.
• Pair programming: Two programmers at one
machine must write all production code in an XP
project.
• Collective ownership: The team owns everything,
implying that anyone can change anything at any
time.

A
Implementing XP: The 12 Practices
• Continuous integration: Integrate and build
every time a task is finished, possibly several
times a day (as long as the tests all pass).
• 40-hour week: Work a regular 40-hour week.
Never work a second week in a row with
overtime.
• On-site customer: A customer is part of the
team, is on-site, writes and executes functional
tests, and helps clarify requirements.
• Coding standards: The team has them, follows
them, and uses them to improve
communication.

A
Scrum
• The second agile methodology.
• Scrum is a means of restarting play after a
rules infraction.

A
Scrum Roles
• the requirements normally take the form of
user stories—features that can be summarized
by sentences like
• “As a <type of user>,
• I want to <do or create something>,
• so that <some value is created>.

A
Scrum Roles
• Scrum defines three roles in a development
project.
• product owner, the person who generates the
requirements for the product and prioritizes them.
• Scrum master whose job it is to manage the backlogs,
run the daily Scrum meetings, coach the team, and
protect the team from outside influences during the
sprint.
• the development team itself is self-organizing; the
members of the Scrum team decide among themselves
who will work on what user stories and tasks, assume
collective ownership of the project, and decide on the
development process they’ll use during the sprint.
•

A
The Sprint
• Scrum is characterized by the sprint, an
iteration of between one and four weeks.

A
Scrum Artifacts
• Scrum requirements are encapsulated in two
backlogs.
• The product backlog is the prioritized list of all
the requirements for the project; the product owner
creates it.
• The sprint backlog is the prioritized list of user
stories for the current sprint.

A
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.

A
Lean Software Development
• Lean software development comes from the
just-in-time manufacturing processes (also
known as the Toyota Production System,
among other names) that were introduced in
Japan in the 1970s and then made their way
around the world in the 1980s and 1990s,
encouraged by the publication in 1990 of The
Machine That Changed The World by
Womack, et. al.1

A
seven key principles for software
development:
1. Eliminate Waste. eliminate anything that doesn’t
add value to the product.
2. Build Quality In. Quality issues are the bane of
every software developer.
3. Create Knowledge. The team must learn new things
constantly
4. Defer Commitment. put off decisions (particularly
irreversible ones) as long as you can and only make
them when you must.
5. Deliver Fast. “First to market”
6. Respect People. all about building strong,
productive teams.
7. Optimize the Whole. keep the entire product picture
in sight as you develop.

A
Kanban
• The Kanban method is a practice derived from
lean manufacturing (the Toyota Production
System) and other change-management
systems; it draws most of its original ideas from
the just-in-time manufacturing processes.
• Kanban uses three ideas to influence a
development process:
• Work-in-progress is the total number of tasks the
team is currently working on
• Flow is the passage of tasks from one state to
another on the way to completion.
• Lead time is the amount of time it takes a task to
move from its initial state to its completed state.

A
The Kanban board, WIP, and Flow
• These boards are
often physical white
boards that occupy
one wall of a common
space for the team.

A generic task/Kanban
board

A
A task/Kanban board applied to a
software development project

A
Kanban Software

A
Summary
• As can be seen from the methodologies
described in this chapter, 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.

A
End

A
 Chapter 4
Project Management
Essentials

A
• Project management is 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

A
Project Planning
• Project planning is forever.

• What’s in the project plan? Generally a project

plan consists of the following seven parts:
• Introduction and explanation of the project
• Team organization
• Risk analysis
• Hardware, software, and human resource requirements
• Task list and size and effort estimates
• Project schedule
• Project monitoring and reporting mechanisms,
collectively known as project oversight

A
An agile project plan
• is feature-based (remember it’s built around
getting production code running quickly).
• is organized into iterations.
• is multi-layered (because it knows that things
will change and that the initial set of
requirements are not complete or detailed
enough).
• is owned by the team, not the project manager.

A
Project Organization
• The 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

A
Risk Analysis
• In the risk analysis section, you need to think
about the bad things.

A
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:Requirements churn is
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.
•

A
Resource Requirements
• How many people do you need for the project?

A
Task Estimates
• The first step toward a project schedule is
seeing what you’ll be doing and figuring out
how long each step will take.

A
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.

A
Project Oversight
• Project oversight is what happens once you’ve
got a schedule and your project is underway.

A
Status Reviews and Presentations
• Status reviews and presentations are an
inescapable part of any project. The bigger the
project, the
more formal the review.

A
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.

A
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).
• 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).

A
The Retrospective
• A retrospective, as the name implies, is an
opportunity to reflect on the project just
completed and answer a few questions.

A
The Retrospective
• 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).

A
Summary
• So where do we end up? We’ve gone through
the general parts of managing projects, and
I’ve presented some alternative ways of doing
project management. 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.

A
End

A
 Chapter 5
Software Architecture

A
Two levels of software design
1. Detailed design
• What operations do we need?
• What data structures?
• What algorithms are we using?
• How is the database going to be organized?
• What does the user interface look like?
• What are the calling sequences?

A
Two levels of software design
2. Style
• If you were building a house, this design level
asks questions like ranch or multi-story? Tudor
or Cape Cod? Which direction do the bedroom
windows face? Forced-air or hot-water heat?
Three bedrooms or four? Open concept floor
plan or closed? These questions focus
somewhat on details, but they’re much more
about the style of the house and how you’ll be
using it, rather than things like 12- or 14-gauge
wire for the electrical system or the dimensions
of the air conditioning ductwork.

A
General Architectural Patterns
• Software architectures are normally
represented as black box graphs where graph
nodes are computational structures and the
graph edges are communication conduits
between the structures.

A
Unified Modeling Language
• UML (Unified Modeling Language) is a
standard language for specifying, visualizing,
constructing, and documenting the artifacts of
software systems.

A
Class Notation
• The top section is
used to name the
class.
• The second one is
used to show the
attributes of the
class.
• The third section is
used to describe
the operations
performed by the
class.
• The fourth section
is optional to show
any additional
components.

A
Object Notation
• The object is
represented in the
same way as the
class. The only
difference is
the name which is
underlined as
shown in the
following figure.

A
The Main Program—Subroutine
Architectural Pattern

A
Pipe-and-Filter Architecture
In a pipe-and-filter style architecture, the
computational components are called filters and
they act as transducers that take input, transform it
according to one or more algorithms, and then
output the result to a communications conduit. The
input and outputs conduits are called pipes.

A
Pipe-and-Filter Architecture
• The Problem: Given a dictionary of words in
English, find all the anagrams in the dictionary.
That is, find all the words that are permutations of
each other. For example, pots, stop, and spot are
anagrams of each other.
• Create a sign for each word in the list by sorting the
letters in each word; keep the sign and the word
together.
• Sort the resulting list by the signs; all the anagrams
should now be together.
• Squash the list by putting each set of anagrams on the
same line, removing the signs as you do.
• In Unix-speak it looks like this:
• sign <dictionary.txt | sort | squash >anagrams.txt

A
An Object-Oriented Architectural
Pattern
• The Model-View-Controller (MVC)
architectural pattern is a way of breaking an
application, or even just a piece of an
application’s interface, into three parts: the
model, the view, and the controller. MVC was
originally developed to map the traditional
input, processing, and output roles of many
programs into the GUI realm:
Input ➤ Processing ➤ Output
Controller ➤ Model ➤ View

A
The Model-View-Controller
architecture
• The controller
interprets mouse
and keyboard
inputs from the
user and maps
these user actions
into commands
that are sent to
the model and/or
view to effect the
appropriate
change.

A
The Model-View-Controller
architecture
• The model
manages one or
more data
elements,
responds to
queries about its
state, and
responds to
instructions to
change state.

A
The Model-View-Controller
architecture
• The view or
viewport
manages a
rectangular area
of the display and
is responsible for
presenting data to
the user through a
combination of
graphics and text.

A
A typical fox and rabbit hunt
instance

A
The fox and rabbit hunt class
structure

A
Model
• The model represents the
rules of the game. It does
all the computation and all
the work of deciding whose
turn it is, what happens
during each turn, and
whether anyone has won.
The model is strictly internal
and has practically nothing
to do with the other parts of
the program.

A
View
• The view displays what is
going on. It puts an image
on the screen so the user
can see what’s happening.
The view is completely
passive; it doesn’t affect the
hunt in any way, it’s just a
news reporter that gives you
a (partial) picture of what is
happening inside the model.

A
Controller
• The controller is the part of
the program that displays
the controls (the five
buttons and the speed
controls at the bottom of the
window). It knows as little
as possible about the model
and view; it basically tells
the model when to go and
when to stop.

A
The Client-Server Architectural
Pattern
• program is broken up into two different pieces
that typically run on two separate computers.
• A server does most of the heavy lifting and
computation; it provides services to its clients
across a high-bandwidth network.
• Clients, on the other hand, mostly just handle user
input, display output, and provide communication to
the server.

A
The Layered Approach
• The layered
architectural approach
suggests that
programs can be
structured as a series
of layers, much like
geologic strata, with a
sequence of well-
defined interfaces
between the layers.
A layered architecture

A
 International Standards Organization (ISO) Open
Systems Interconnection (OSI) seven- layer model

Layered Protocols Using the ISO-OSI Architecture

The ISO-OSI Layered archictecture

A
End