2014 Software Design and Development Notes
Uploaded by
skyrunner312014 Software Design and Development Notes
Uploaded by
skyrunner31S D D
H S C
N O T E S
TABLE
OF
CONTENTS
9.1
Development
and
Impact
of
Software
Solutions
9.1.1
Social
and
Ethical
Issues
The
Impact
Of
Software
Rights
and
Responsibilities
of
Software
Developers
Software
Piracy
and
Copyright
Use
Of
Networks
The
Software
Market
Legal
Implications
9.1.2
Application
of
software
Development
Approaches
Software
Development
Approaches
Use
Of
Computer
Aided
Software
Engineering
Methods
Of
Installation
Of
New
Or
Updated
Systems
Employment
Trends
In
Software
Development
Trends
In
Software
Development
2
2
2
3
6
9
9
10
11
11
14
15
16
16
9.2 Software development cycle
9.2.1 Defining And Understanding The Problem
Defining The Problem
Issues Relevent To A Proposed Solution
Design Specifications
System Documentation
Communication Issues Between Client And Developer
9.2.2 Planning And Designing Software Solutions
Standard Algorithms
Custom-Designed Logic Used In Software Solutions
Standard Modules (Library Routines) Used In Software Solutions
Interface Design
Factors Considered When Selecting Programming Language
Factors Considered When Selecting Technology
9.2.3 Implementation Of Software Solutions
Language Syntax Required For Software Solutions
The Need For Translation To machine Code From Source Code
The Role Of Machine Code In The Execution Of A Problem
Techniques Used In Developing Well-Writen Code
Documentation of A Software Solution
Hardware Environment To Enable Implementation Of The Software
9.2.4 Testing And Evaluating Of Software Solutions
Testing The Software Solution
Reporting On The Testing Process
Evaluating The Software Solution
Post Implementation Review
9.2.5 Maintaing Software Solutions
Modifying Code To Meet Changed Requirements
Documenting Change
17
17
17
18
19
21
31
31
31
41
45
46
47
47
48
48
49
51
53
57
59
60
60
63
65
66
66
66
67
9.4
Options
9.4.1
Option
1
Programming
Paradigms
69
69
Adam Florence SDD HSC Notes
Development Of Different Paradigms
Logic Paradigm
Object Oriented Paradigm
Issues With The Selection Of An Appropriate Paradigm
defined.
69
71
77
Error!
Bookmark
not
9.1 DEVELOPMENT AND IMPACT OF SOFTWARE SOLUTIONS
9.1.1 SOCIAL AND ETHICAL ISSUES
THE IMPACT OF SOFTWARE
THE Y2K PROBLEM
In the 60s and 70s storage was expensive so software was required to use the absolute
minimum amount of storage space. To cater to this need, software developers often used
only 2 digits to represent the year within dates. It was never thought that these products
would still be in use when the year 2000 came along. As a result, many computer systems
failed, and also a variety of incorrect calculations, and computer crashes occurred.
COMPUTER MALWARE
Malware includes any software, which performs an unwanted and unvisited task. Anti-virus
and anti-spyware utilities are installed to detect and destroy malware and to advise users of
potentially unsafe practices or websites.
Examples of malware include:
Viruses- viruses are commonly attached or embedded within apparently legitimate
software or files. As the software is executed, the virus is also able to execute,
duplicate itself and perform its malicious processing
Worms- worms are a type of virus that aims to slow down a system. They exploit a
security flaw in the OS and then install themselves on the hard drive. Over time
worms continue to execute copies of themselves, and consume the entire disk
Trojan horses- often used to install malware that enables an outside user to take
control of your computer
Spyware- Aims to obtain your information without your knowledge. Some spyware
is able to capture your browser history, emails and read keystrokes as you enter
passwords and credit card details
RELIANCE ON SOFTWARE
Household
appliances
such
as
ovens,
TVs,
washing
machines
and
stereos
all
rely
on
software
to
operate.
All
types
of
motorized
transport
are
controlled
by
software.
Utilities
rely
on
software.
Government
authorities
are
all
software
reliant
in
some
form.
The
software
development
industry
has
a
huge
responsibility
has
a
huge
responsibility
to
ensure
all
these
systems
are
reliable
and
perform
their
various
functions
accurately.
SOCIAL
NETWORKING
A
social
network
is
simply
a
group
of
people
who
associate
with
each
other.
Recently
the
concept
of
social
networks
has
rapidly
expanded
into
the
online
world.
Private
and
personal
information
is
all
too
easily
shared
and
this
can
lead
to
a
variety
of
problems
including
identity
theft,
stalking
and
cyber
bullying.
Comments
made
on
an
online
site
can
remain
Adam Florence SDD HSC Notes
accessible
indefinitely.
These
comments
may
be
embarrassing
when
viewed
by
some
future
employer
or
by
future
children
or
friends.
CYBER
SAFETY
The
online
world
of
the
internet
includes
a
variety
of
different
dangers
and
security
issues.
All
internet-connected
devices
have
risks.
Cyber
safety
is
about
minimizing
the
risk
of
such
dangers,
particularly
for
children.
This
is
some
of
the
recommendations
of
cyber
safety
are:
Locations
based
services-
this
makes
it
easy
for
unknown
people
to
find
you
and
it
also
alerts
them
that
you
are
not
home.
It
is
wise
to
turn
off
location
tracking
unless
required
Unwanted
contact-
if
you
receive
message
from
an
unknown
person,
do
not
respond
Cyber
bullying-
when
online,
spreading
false
rumours,
teasing
or
making
threats
online
is
unacceptable
Online
friends-
be
aware
that
people
may
not
be
who
they
claim
to
be,
it
is
prudent
to
not
share
private
information
to
those
you
do
not
know
in
real
life
Online
purchasing-
it
is
prudent
to
restrict
online
purchases
to
well
known
organisations
and
examine
the
details
and
conditions
for
sale
Identity
theft-
criminals
can
obtain
sufficient
information
about
you
so
they
are
able
to
use
your
credit
card,
access
your
bank
account
or
take
out
loans
in
your
name.
Be
careful
with
your
personal
information
EVALUATING
AVAILIABLE
INFORMATION
Huge
amounts
of
information
are
publicly
available
through
the
internet.
Information
is
uploaded
by
anybody
regardless
of
his
or
her
qualifications,
expertise
or
experience
and
in
many
cases
it
is
difficult
to
identify
the
author.
On
the
internet
biased,
unsupported,
unverifiable,
misleading
and
often
incorrect
information
is
common.
When
reading
online
information
you
should
question:
Who is the author?
Is the information up-to-date?
Who is the intended audience?
Is the information accurate and unbiased?
What is the purpose of the information?
RIGHTS AND RESPONSIBILITIES OF SOFTWARE DEVELOPERS
Software developers have rights in regard to how other people may use and duplicate their
products. Along with these rights come responsibilities. Developers of software products are
accountable to their customers to provide solutions that are of high quality, ergonomic,
inclusive, and free of malware and above all perform their stated task correctly and
efficiently. Responsible developers will provide systems that allow them to respond to
problems encountered by users. Many developers voluntarily adhere to a professional code
of conduct.
CODE OF CONDUCT
A code of conduct is a set of standards by which software developers agree to abide. Many
professional software developers are members of professional associations that expect
adherence to a written code of conduct. It is the responsibility of the individual developer to
uphold the code of conduct. Accepted codes of conduct increase standards across the entire
industry.
ERGONOMIC ISSUES
Adam Florence SDD HSC Notes
Ergonomics
is
the
study
of
the
interactions
between
human
workers
and
their
work
environment.
As
the
user
interface
provides
the
connection
between
software
and
users,
the
design
and
operation
of
the
screens
is
of
primary
interest.
Usability
testing
should
then
be
performed
throughout
the
design
process
to
ensure
the
software
is
ergonomically
sound.
User
support
including
help
screens
and
other
forms
of
user
training
and
assistance
is
another
important
area.
INCLUSIVITY
ISSUES
Inclusive
software
should
take
into
account
the
different
users
who
will
likely
use
the
product.
Software
developers
have
a
responsibility
to
ensure
software
is
accessible
to
all
regardless
of
their
culture,
economics,
gender
or
disability.
Software
products
that
do
not
take
into
account
the
different
characteristics
of
users
are
less
likely
to
secure
a
significant
market
share.
Cultural
background:
Developers
must
understand
the
needs
of
other
cultures.
Names,
numbers,
currency,
times
and
dates
are
common
areas
of
difference.
For
example
in
some
Asian
cultures,
people
dont
have
only
given
name
and
a
surname,
and
in
some
countries
different
calendars
are
used.
Many
large-scale
systems
manage
to
utilise
any
number
of
languages,
so
the
application
can
be
customised
to
suit
any
foreign
language,
in
effort
to
increase
inclusivity.
Economic
background:
Software
developers
have
a
responsibility
to
ensure
consideration
is
given
to
the
economic
situation
of
purchasers
of
software
products.
To
achieve
equality
of
access
to
technologies
such
as
software
requires
that
the
technology
is
available
at
a
cost
that
is
economically
viable
for
a
wide
audience.
Gender:
Both
men
and
women
should
be
included
in
the
software
design
and
development
process.
Programming
is
viewed
as
a
technical,
mathematical
process
with
rigid
boundaries.
Research
shows
that
men
tend
to
dominate
in
these
types
of
occupations.
Since
men
are
engaged
in
the
creation
of
software,
it
follows
that
some
bias
is
likely
to
exist
towards
males
within
the
software
products
they
develop.
Disability:
Software
design
should
include
functionality
that
allows
software
to
be
used
and
accessed
by
a
wide
range
of
users.
The
computer
has
revolutionised
the
lives
of
many
disabled
people.
To
ensure
maximum
accessibility
to
those
users
with
a
disability,
software
designers
have
a
number
of
tools
and
techniques
at
their
disposal.
The
choice
of
larger
fonts
helps
those
with
visual
disabilities.
Colour
may
not
be
used
for
the
sole
purpose
of
conveying
information,
so
the
colour-blind
can
still
used
the
software.
Software
should
not
rely
on
sound
as
the
sole
method
of
communication
of
information,
this
is
so
deaf
people
are
included
in
the
use
of
the
software.
INTELLECTUAL
PROPERTY
Adam Florence SDD HSC Notes
Intellectual
property
is
property
resulting
from
mental
labour.
Therefore
all
types
of
authors,
including
software
developers,
create
intellectual
property.
With
most
literary
works
it
is
clear
who
the
author
is
and
therefore
it
is
clear
who
owns
the
intellectual
property
rights.
In
the
case
of
software
products,
the
situation
is
often
not
clear,
for
example:
A software product is written in a programming language, which was developed by
another company
Some modules of source code are purchased from other companies
The artwork for images, video and animation is designed and created by a graphic
design company
All
the
people
and
companies
involved
in
the
original
creation
of
this
software
package
are
authors
and
have
intellectual
property
right
in
regard
to
their
particular
original
contribution.
Different
contributors
to
a
software
product
will
have
differing
requirements
in
regard
to
their
intellectual
property.
Copyright
laws
are
designed
to
protect
the
intellectual
property
right
of
all
the
authors
involved.
MALWARE
Malware
is
software
that
is
intended
to
damage
or
disable
computers
and
computer
systems.
Software
developers
have
a
responsibility
to
ensure
their
products
do
not
contain
malware.
To
make
sure
this
is
the
case
they
should
check
any
new
data
and
software
being
added
to
their
computers
for
viruses.
Purchasers
of
software
have
the
right
to
expect
software
they
purchase
is
free
of
all
malware.
Developers
can
be
held
responsible
for
distributing
malware
with
their
products.
PRIVACY
ISSUES
Privacy
is
about
protecting
an
individuals
personal
information.
Privacy
is
a
fundamental
principle
of
our
society,
and
we
have
the
right
to
know
who
holds
our
personal
information.
Personal
information
is
legitimately
required
by
many
organisations
when
carrying
out
their
various
functions.
This
creates
a
problem,
how
do
we
ensure
this
information
is
used
only
for
its
intended
task
and
how
do
we
know
what
these
intended
tasks
are?
Laws
are
needed
that
require
organisations
to
provide
individuals
with
answers
to
these
questions.
In
this
way
individuals
can
protect
their
privacy.
Consequences
of
the
Privacy
Act
1988
means
that
information
systems
that
contain
personal
information
must
legally
be
able
to:
Explain
why
personal
information
is
being
collected
and
how
it
will
be
used
Provides
individuals
with
access
to
their
records
Divulge
details
of
other
organisation
that
may
be
provided
with
information
from
the
system
The
final
quality
of
a
software
development
project
is
an
important
responsibility
for
all
software
developers.
To
develop
high
quality
applications
is
time
consuming
and
costly.
Often
compromises
have
to
be
made
because
of
financial
constraints.
Quality
software
is
developed
as
a
result
of
thorough
planning
and
testing.
Many
companies
have
developed
sets
of
standards
to
which
their
employees
must
adhere.
Quality
assurance
is
used
to
ensure
that
these
standards
are
observed.
It
attempts
to
make
sure
that
customer
expectations
are
met
and/or
exceeded.
All
customers
have
a
right
to
have
their
expectations
met,
and
it
is
the
responsibility
of
the
developer
to
make
sure
this
occurs.
It
is
Adam Florence SDD HSC Notes
in
the
developers
best
interest
to
know
the
customers
requirements
and
to
exceed
their
expectations
if
they
are
to
continue
to
operate
profitably.
Factors
that
affect
software
quality
include:
Correctness, doing what its supposed to
Reliability, doing it consistently
Efficiency, doing it the best way possible
Integrity, doing it securely
Useability, is it designed for the end-user
Maintainability, is it understandable
Flexibility, can it be modified
Testability, can it be tested
Portability, will it work with other hardware
Re-usability, can parts of it be used on something else
External factors affecting quality:
Hardware, developers should test their product with a number of different
hardware devices
Operating system, developer must consider the effects the operating system has on
the software product
Other software, can affect the quality of the developers product. Responsibility to
ensure other software doesnt affect the reliability of their product
Runtime errors, all applications must include error checking built-in. responsibility to
ensure that errors are dealt with so execution continue
RESPONSE TO PROBLEMS
Software
developers
have
a
responsibility
to
ensure
that
any
problems
users
encounter
with
their
product
is
resolved
in
a
timely,
accurate
and
efficient
manner.
The
developer
needs
to
ensure
there
is
a
mechanism
in
place
to
assist
in
the
identification
of
errors
and
their
subsequent
resolution.
SOFTWARE PIRACY AND COPYRIGHT
CONCEPTS ASSOCIATED WITH PIRACY AND COPYRIGHT
PLAGIARISM
Plagiarism is appropriating or imitating anothers ideas and manner of expressing them and
claiming them as your own. When somebody passes off someone elses creation as his or
her own, they are plagiarising that persons work.
Plagiarism is not always clear, many people and products are involves in the creation of new
software. Often code is modified to suit a new task, overall any contribution to a project
needs to be acknowledged and work obtained from other sources should never be said to be
your own.
COPYRIGHT LAWS
Copyright laws are in place to safeguard the legal intellectual property rights of authors of
any original works. The purpose of these copyright laws is to provide economic incentives
for creative activity, hence promoting the progress of creative endeavour. Copyright
protects the expression of ideas rather than the ideas themselves. As the word copyright
implies, the copyright laws give the owner the sole right to reproduce the work.
The following includes some of the general laws of copyright:
Adam Florence SDD HSC Notes
The right to reproduce copyrighted work
The right to make derivative works, e.g. a movie from a novel
The right to distribute copyrighted works to the public
The right to perform and display certain works in public, e.g. music and art
One copy may be made for backup purposes only
When ownership of a licence is transferred, all copies must be handed over or
destroyed
Decompilation and reverse engineering are not permitted. However a product may
be decompiled or reverse engineered to provide information to other developers in
regard to their product interfacing with the copyrighted product
LICENSE CONDITIONS
Software
licences
are
intended
to
enforce
the
intellectual
property
rights
of
software
developers.
These
licence
agreements
are
enforceable
by
law,
including
copyright
laws.
As
well
as
protecting
the
intellectual
property
rights
of
software
developers,
licence
agreements
also
protect
developers
from
legal
action
should
their
products
result
in
hardship
or
financial
loss
to
purchasers.
Licence
terminology:
Licence.
Formal
permission
or
authority
to
use
a
product.
Licence
does
not
give
users
ownership
of
the
software,
rather
they
are
granted
the
right
to
use
the
software
Agreement.
A
mutual
arrangement
between
parties
Term.
The
period
of
time
the
agreement
is
in
force
Warranty.
An
assurance
of
some
sort.
Software
products
normally
contain
limited
warranties
Limited
use.
Software
licences
do
not
give
purchasers
unrestricted
use
of
the
product.
Commonly
usage
of
software
products
is
restricted
to
a
single
machine,
copying
of
the
product
is
not
permitted
Liability.
An
obligation
or
debt
as
a
consequence
of
some
event.
Licence
agreements
normally
restrict
the
liability
of
the
software
developer
to
replacing
the
product
or
refunding
the
purchase
price
should
an
error
or
other
problem
occur
Program.
Refers
to
the
computer
software.
This
usually
includes
both
executable
files
and
included
data
file.
Reverse
engineer.
In
terms
of
software,
this
usually
means
the
process
of
decompiling
the
product
Backup
copy.
A
copy
of
the
software
made
for
archival
purposes
CLASSIFICATIONS
OF
SOFTWARE
IN
TERMS
OF
COPYRIGHT
COMMERCIAL
Most software is commercial software purchased from software publishers, computers
stores and other retailers and software distributers. You are actually purchasing a license to
use the software. Commercial software licenses state that; the software is covered by
copyright, one archival copy may be made for use only if the original fails, modifications to
the software are not permitted, reverse engineering and decompilation are not permitted,
use of the work as part of another package is not allowed without permission.
OPEN SOURCE
Although covered by copyright law, open source licences specifically remove many
traditional copyrights. The open source code is developed collaboratively and is available to
all to modify and redistribute. The only significant restrictions are that the author is
Adam Florence SDD HSC Notes
recognised
and
that
modified
products
must
be
released
using
the
same
unrestricted
open
source
licence.
SHAREWARE
Shareware
is
covered
by
copyright.
As
with
commercial
software,
you
are
acquiring
a
licence
to
use
the
product.
Purchasers
are
allowed
to
make
and
distribute
copies
of
the
software.
Once
you
have
tested
the
software
and
decided
to
use
it,
you
must
pay
for
it.
As
with
commercial
licenses,
decompilation,
reverse
engineering
and
modifications
are
not
permitted.
PUBLIC
DOMAIN
Software
becomes
public
domain
when
the
copyrights
holder
explicitly
relinquishes
all
rights
to
the
software.
Just
because
a
product
does
not
bear
a
copyright
symbol
does
not
mean
that
it
is
not
covered
by
copyright,
public
domain
software
must
be
clearly
marked
as
such.
OWNSERHIP
VERSUS
LICENSING
The
user
does
not
generally
own
software
obtained
from
outside
sources.
The
software
developer
who
is
the
author
of
the
product
retains
ownership
of
the
product.
REVERSE
ENGINEERING
Analysing
a
product
and
its
parts
to
understand
how
it
works
and
to
recreate
its
original
design,
usually
with
the
purpose
of
creating
a
similar
product
based
on
this
design.
DECOMPILATION
The
opposite
of
compilation,
translating
machine
executable
code
into
a
higher-code.
This
allows
the
programs
design
to
be
more
easily
understood.
TECHNOLOGIES
USED
TO
COMBAT
SOFTWARE
PIRACY
Without
some
form
of
protection,
software
is
simple
to
copy
and
it
is
virtually
impossible
to
determine
that
a
copy
has
been
made.
Over
the
years
a
variety
of
different
technologies
and
strategies
have
been
used
in
an
attempt
to
minimise
the
possibility
for
piracy.
NON-COPYABLE
DATASHEET
The
user
needs
to
enter
codes
from
the
datasheet
to
continue
using
the
software.
E.g.
software
products
include
datasheets
printed
using
inks
that
could
not
be
copied,
so
when
the
software
is
pirated
they
dont
have
the
datasheet.
HARDWARE
SERIAL
NUMBERS
A
variety
of
hardware
components
within
every
computer
include
an
embedded
serial
number,
which
cant
be
altered.
Software
can
be
designed
so
that
it
examines
these
serial
numbers
and
if
they
dont
match
then
the
program
will
not
execute.
SITE
LICENCE
INSTALLATION
COUNTER
ON
A
NETWORK
In
larger
organisations
software
is
often
installed
from
a
network
server.
The
organisation
purchases
a
site
licence,
which
specifies
the
maximum
number
of
machines
who
may
either
install
or
simultaneously
execute
the
product.
REGISTRATION
CODE
A
registration
code
is
used
to
activate
software
products
during
the
initial
stage
in
the
installation
process.
For
single
software
licences
the
registration
code
in
unique
to
your
installation.
Some
software
applies
an
algorithm
to
the
registration
code
so
that
it
is
verified
as
correct.
ENCRYPTION
KEY
Adam Florence SDD HSC Notes
Encryption
effectively
scrambles
the
data
or
executable
code
in
such
a
way
that
it
is
virtually
impossible
to
make
sense.
The
encryption
key
is
required
to
reverse
the
encryption
process.
Once
entered
the
software
is
decrypted.
BACK-TO-BASE
AUTHENTICATION
Back-to-base
authentication
means
the
application
contacts
the
software
publishers
server
to
verify
the
user
or
computer
holds
a
valid
software
licence.
If
the
licence
is
verified
as
correct
then
the
software
will
execute.
USE
OF
NETWORKS
A
network
is
a
collection
of
computers
connected
electronically
to
facilitate
the
transfer
of
data
and
software.
The
widespread
use
of
networks,
including
the
internet,
has
revolutionised
the
development
of
software.
The
ability
to
collaborate
and
share
resources
greatly
improves
productivity.
Changes
to
the
user
interface
in
terms
of
how
data
is
entered
and
retrieved
across
the
network
can
greatly
improve
response
times.
BY
THE
DEVELOPER
WHEN
DEVLOPING
SOFTWARE
Currently
all
but
the
smallest
software
applications
are
developed
collaboratively,
by
a
team
of
developers.
In
many
cases
the
programmers
have
never
met
in
person
and
may
live
in
different
countries.
Without
networks,
in
particular
the
internet,
many
of
the
applications
we
use
on
a
daily
basis
would
not
exist.
In
addition
to
communicating
with
other
developers,
many
programming
language
libraries
and
related
documentation
reside
on
the
web.
During
coding,
programmers
are
able
to
research
and
then
in
an
instant
download
and
incorporate
existing
source
code
into
their
application.
BY
THE
USER
WHEN
USING
NETWORK
BASED
SOFTWARE
Even
sites
that
generally
respond
quickly
can
experience
poor
response
times
during
periods
of
high
activity.
For
software
developers,
response
times
can
be
difficult
to
control
with
certainty.
Although
media-rich
content
can
look
amazing,
it
will
have
little
impact
if
nobody
can
be
bothered
waiting
for
it
to
load.
When
embedded
video
and
large
images
are
included,
then
response
times
will
be
severely
compromised.
Text
based
content
is
many
times
smaller
in
terms
of
file
size
compared
to
video
and
images.
THE SOFTWARE MARKET
MAINTAINING MARKET POSITION
Maintaining a software companys standing and position in the market requires that the
company consider social and ethical issues when developing marketing techniques and
strategies. The effect of not considering social and ethical issues will result in undermining
the confidence of consumers to trust the assertions of software companies.
Marketing is described in terms of:
Product- the expectations of consumers must be realised in the actual output. It is
unethical for a product to not live up to the expected functionality desired by
customers
Place- where software is sold is related to the type of product and its intended
audience. Shops, industry specific distributors and direct sales are methods of
distribution of software
Adam Florence SDD HSC Notes
Price-
consumer-based
pricing
involves
looking
at
what
the
consumer
wants
and
how
much
they
are
willing
to
pay
for
it
Promotion-
advertising
can
be
helpful
to
consumers
who
are
investigating
what
is
available
in
the
marketplace.
These
advertising
activities
should
provide
accurate
information
that
is
inoffensive
and
not
misleading
THE
EFFECT
OF
DOMINANT
DEVELOPERS
OF
SOFTWARE
If
one
players
product
dominates,
then
it
becomes
the
default
purchase.
This
is
largely
what
has
occurred
in
the
OS
market
and
also
in
the
word
processer
and
spread
sheet
market.
It
requires
effort
on
the
part
of
the
user
to
even
purchase
a
computer
without
Windows.
THE
IMPACT
OF
NEW
DEVELOPERS
OF
SOFTWARE
AND
NEW
PRODUCTS
Although
there
are
companies
and
products,
which
dominate
existing
software
markets,
there
is
still
room
for
new
players.
Often
new
developers
emerge
due
to
inventiveness.
That
is,
they
invent
a
new
software
product
the
breaks
new
ground.
Both
Google
and
Facebook
are
prominent
examples
of
companies,
which
began
with
a
bright
idea.
Currently
small
software
applications
for
mobile
phones
are
creating
a
significant
market.
Apps
for
android
and
Apple
can
sell
in
the
millions.
Otherwise
unknown
developers
are
able
to
access
an
enormous
worldwide
market
using
the
Android
and
Apple
store.
LEGAL
IMPLICATIONS
There
are
many
significant
social
and
ethical
issues
that
need
to
be
considered
by
those
in
the
business
of
creating
and
distributing
software.
Software
implemented
on
systems
throughout
a
country
can
result
in
significant
legal
action
if
the
software
contravenes
the
law
of
the
country
in
some
way
or
its
development
does
not
comply
with
the
legal
contract
between
the
software
developer
and
the
customer.
The
legal
actions
may
be
the
result
of
copyright
breaches
or
can
arise
when
software
does
not
perform
as
intended.
National
legal
cases
include:
RACV versus Unisys:
The RACV is a motor vehicle and general insurance company similar in nature to the
NRMA. In 1993 the RACV issued a Request for Proposal after making the decision to
convert from its current paper-based claims management system to an electronic
storage and retrieval system.
Unisys Systems won the proposal to supply RACV with their new system, one that
would lead to more efficient handling of claims. During presentations of the new
system, Unisys assured RACV that the response times and functionality shown
during demonstration would be indicative of the live system.
When the system was delivered, the response times and functionality failed to
eventuate. RACV terminated their contract with Unisys and sought damages through
the courts citing false representation and misleading conduct with regard to the
functionality of the system. The court awarded damages of $4 million to RACV.
Microsoft versus Netscape:
In 1996, the battle for market share, of web browsers, between Netscape and
Microsoft began. In 1997 Microsoft packaged Internet Explorer 4 with Windows 95.
Microsoft integrated the web into Windows 95. Netscape filed lawsuits against
Microsoft, alleging Microsoft was taking illegal advantage due to their vast share of
the OS market. Microsofts response was that Internet Explorer was an integral part
of their OS. No real resolution was ever reached.
International legal cases include:
Adam Florence SDD HSC Notes
10
Google versus Chinas national censorship laws:
Google China first began operations in 2005. In early 2009, China blocked access to
Googles YouTube. Google responded with an announcement that they were no
longer willing to censor searches in China and that they may pull out of China
altogether. Google redirected all Google China searches to Google Hong Kong. China
then banned access to all Google sites.
Google was due to have its licence to operate in China renewed in 2010. When this
happened, Google restored its China search engine complete with censorship. They
did include a link to their Hong Kong site. Both Google and the Chinese government
claimed victory.
Napster versus Metallica:
Napster was a Peer-to-Peer file sharing internet service that allowed people to share
music without having to purchase it. In 1999, the Recording Industry Association of
America filed a lawsuit on behalf of five major US record labels alleging that Napster
violated both Federal and State copyright laws and stated that Napster built a
business based on copyright infringement. The judge issued an injunction to have
the site shutdown.
Napster reached a partial settlement of the lawsuits filed against it and agreed to
pay $26 million to some music publishers and songwriters. Napster also states that it
intends to become a subscription-based service with a percentage of royalties being
distributed to the copyright owners. Agreement could not be reached and Napster
filed for bankruptcy.
9.1.2 APPLICATION OF SOFTWARE DEVELOPMENT APPROACHES
SOFTWARE DEVELOPMENT APPROACHES
When new software products are first considered for development the initial planning is
vital. Software development companies need to decide on the most appropriate software
development approach, as well as what resources they will require to complete the task in
the most efficient manner.
A software development approach is a model of the general technique used to produce a
software product. All software development approaches use the five steps of the software
development cycle. These steps are:
1. Defining and understanding the problem. The problem to be solved is defined and
an understanding of the problem is developed
2. Planning and design. The solution is designed
3. Implementation. This is where the algorithm is coded into a computer language
4. Testing and evaluating. Which is the testing of the software which occurs
throughout the process
5. Maintenance. The operation and maintenance of the program
It is the timing and frequency of these steps that changes for different approaches. For
example, in the structured approach each step must be completed before progressing to the
next step. However in agile and prototyping approach these steps will be continually
revisited, as the product is progressively refined.
The approach chosen is influenced by:
The size of the product
The nature of the product
Adam Florence SDD HSC Notes
11
The skills of the personnel
The detail of the requirements
The finances available to fund the product development
AGILE
Agile
methods
remove
the
need
for
detailed
requirements
and
complex
design
documentation.
Agile
emphasises
teamwork
rather
than
following
predefined
structure
development
processes.
Characteristics
of
an
agile
software
development
approach:
Speed of getting a working solution to market or to users. Basic functionality is
included so operational software can be released as soon as possible
Interaction within the team and users which allows the solution to be selectively
refined throughout the development process
Working versions of the software are regularly delivered. Each version adds the next
most important functions
Responds well to changing specifications
Development team and clients collaborate closely throughout development. Often a
client representative or user is part of the team. The needs and ongoing feedback of
the client and users drives the direction of the development
Reasons For Use
Advantages
Disadvantages
- Client has shifting
specifications
- The problem is
undefined of
unclear
- Allows for flexible and rapid
response to changing
specifications
- Constantly working build
- Low levels of documentation
- Low
levels
of
documentation
END-USER
DEVELOPMENT
When
the
end-user
develops
the
software
themselves.
Useful
as
the
user
solves
his
own
problem
quickly.
There
is
a
lack
of
formal
stages.
Reasons For Use
Advantages
Disadvantages
- Quickly
needed
system
- User
has
knowledge
to
develop
for
themselves
- Short
lifespan
- Involves the use of COTS. Fourth
generation languages such as
spread sheets, database
management system
- Cheap to make
- Repetition
of
processes
PROTOTYPING
Prototyping
has
high
interaction
between
customers
and
developers.
A
prototype
is
a
model
of
a
software
system
that
enables
evaluation
of
features
and
functions
in
an
operational
scenario.
The
prototypes
are
created
to
progressively
refine
user
requirements.
Throughout
the
development
process
the
customer
successively
validates
the
product.
Adam Florence SDD HSC Notes
12
Each
successive
prototype
will
better
meet
the
original
requirements
for
the
final
product.
Often
the
prototypes
are
simply
interactive
models
of
the
user
interface.
Prototypes
are
more
about
getting
the
GUI
right
and
will
not
deal
with
security
or
error
recovery.
Information-gathering
prototypes
are
developed
to
gather
information
that
can
be
used
in
another
program.
Concentrates
on
input
and
output
with
minimal
processing,
its
never
intended
to
be
a
full
working
program.
Evolutionary
prototypes
become
the
full
working
program.
Reasons For Use
Advantages
Disadvantages
- When the users of a
system are unclear as to
the requirements
- User evaluation is used
to further refine the
prototype and problem
definition
- Suitable for small scale
projects, with small
budgets and
development time
- Small number of people
- Tests new design
- Doesnt work
features
well for larger
- Used to gain information
projects
and feedback and then
either thrown away or
refined
- Produces a software
application in a shorter
time at a reduced cost to
the client
- Less formal stages
RAPID APPLICATION DEVELOPMENT- RAD
Quickly generates a program for the user. It allows usable systems to be built within a small
amount of time. RAD uses existing modules, CASE tools, and templates and reuses code.
RAD tries to get a working product up and operational as fast as possible, even if secondary
requirements are not met.
Reasons For Use
Advantages
Disadvantages
- Need for quick
production
- Low budget
- Simple system
- Short lifespan
- Low
cost
projects
- Small
team
needed
- Many requirements may not
be met
STRUCTURED
APPROACH
The
structured
approach
involves
very
structured,
step-by-step
stages.
Each
stage
of
the
development
cycle
must
be
completed
before
progressing
to
the
next
step.
This
is
because
one
stage
would
not
work
without
previously
completed
the
previous
stage,
you
cant
implement
a
solution
until
you
consider
potential
solutions,
and
potential
solutions
cant
be
known
until
the
problem
is
defined.
The
structured
approach
is
the
mostly
lengthy
and
costly
approach.
It
involves
many
people
including
system
analyst,
software
engineers,
programmers,
graphic
designers,
consultants,
managers
and
trainers.
The
stages
work
as
follows:
1. Defining
the
problem.
This
involves
thoroughly
understanding
and
defining
the
problem.
Little
time
and
cost
will
be
required
to
fix
any
problems
at
this
phase.
It
Adam Florence SDD HSC Notes
13
2.
3.
4.
5.
takes
on
third
of
the
development
time,
the
end
report
may
need
to
be
repeatedly
modified
until
all
personnel
are
convinced
that
it
will
solve
the
problem
Planning
the
solution.
Further
understanding
of
user
needs
and
methods
to
solve
a
problem
are
undertaken,
data
will
be
collected
from
surveys
and
interviews
to
provide
and
basis
for
the
decision.
Plan
what
data
and
structures
are
to
be
used
(dataflow
diagrams,
IPO
charts,
structured
chart),
design
algorithms,
plan
user
interface
(screen
designs
and
storyboards),
plan
scheduling
(Gantt
chart)
Building
the
solution.
Stepwise
refinement
is
used,
i.e.
overall
problem
is
divided
into
smaller,
more
easily
managed
modules.
Greater
efficiency
as
all
members
can
design
and
test
different
modules
separately,
all
at
the
same
time.
The
program
is
coded
according
to
the
algorithms,
and
modules
are
tested
throughout
code
development
to
ensure
there
are
no
errors
Testing
the
solution.
Testing
the
problem
with
real
data
with
acceptance
and
beta
testing.
When
a
program
is
free
of
error,
it
is
passed
by
the
system
analyst,
when
the
management
approves
the
program
Maintenance.
Modification
required
after
the
program
has
been
implemented.
Updates
lead
to
greater
efficiency,
solve
bugs
caused
by
external
factors.
Changes
are
very
expensive
at
this
stage,
and
are
only
undertaken
if
changes
are
small
and
crucial.
If
a
major
update
is
needed,
better
results
could
be
achieved
by
beginning
the
development
cycle
again
Reasons For Use
Advantages
Disadvantages
Large scale projects
Complex projects
Large budgets
Considerable available time
When a program that is easy to
understand and modify is
needed
- Project development team is
involved
- Easy to write, reusing
modules
- Easy to understand,
lots of documentation
- East to test and debug
- Easy to modify
- Tried and tested
method
- Time
consuming
- Expensive
USE OF COMPUTER AIDED SOFTWARE ENGINEERING
CASE tools are used to assist and coordinate the activities involved in the process of
software development. Any software tool that is used to assist developers can be classified
as a CASE tool. Simple drawing programs can be used to create dataflow diagrams, system
flowcharts and algorithms. Text processors could be used to create all forms of
documentation. For larger systems, where a team of developers is at work, more complex
CASE tools dedicated to software development are available. These tools provide a
development environment that encourages a structured, organised approach to software
creation. Many CASE tools provide all or some of the following functions:
Production
of
code
Production
of
documentation
Test
data
generation
Software
versioning
ORACLE
DESIGNER
Oracle
Designer
is
a
CASE
tool
that
specialises
in
system
design,
from
creating
a
process
model
through
various
system
modelling
diagrams
and
finally
to
the
creation
of
source
code
Adam Florence SDD HSC Notes
14
and
user
interfaces.
Oracle
Designer
uses
an
area
to
store
preferences
used
in
the
generation
of
the
final
source
code
and
user
interfaces.
The
code
created
can
then
be
loaded
into
the
languages
development
environment
for
further
modification
before
being
compiled.
This
product
aims
at
teams
of
developers,
and
hence
it
allows
multiple
users
to
access
and
modify
aspects
of
the
development
of
a
product.
Each
object
in
the
project
contains
its
own
versioning
system.
Previous
versions
of
object
are
maintained,
so
unwanted
changes
can
always
be
deleted.
AXIOM
SYS
AxiomSys
is
a
system
requirements
modelling
CASE
tool.
It
can
be
used
to
generate
dataflow
diagrams
for
systems
of
all
types,
not
just
software
systems.
This
tool
allows
for
the
creation
of
modularised
dataflow
diagrams
together
with
data
dictionary
capabilities
in
regard
to
all
data
flows.
DATAFACTORY
DataFactory
is
a
test
data
generation
CASE
tool.
This
tool
is
able
to
create
fandom
test
data
in
large
quantities.
It
is
especially
suited
to
testing
large,
data-oriented
applications.
Hundreds
of
thousands
of
records
can
be
generated
using
data
of
user-specified
data
types.
Products
such
as
DataFactory
allow
real
world
testing
of
applications
without
the
need
for
massive
amounts
of
data
to
be
manually
input
or
scanned.
METHODS OF INSTALLATION OF NEW OR UPDATED SYSTEMS
Once a new software product has been produced it must
be installed and then implemented on site. There are a
number of methods of introducing a new system and each
of these methods suits different circumstances. The four
common methods of installation are:
PARALLEL
The parallel method of installation involves operating
both systems together for a period. This allows any major
problems with the new system to be encountered and
corrected without the loss of data. Parallel conversion also means users of the system have
time to familiarise themselves fully with the operation of the new system. Once the new
system is found to be meeting requirements then operation of the old system can cease.
The parallel method involves double the workload for users, as all function must be
performed on both the old and the new systems. This method is especially useful when the
product is of a crucial nature, dire consequences would results if the new system were to
fail.
PILOT
With the pilot method of installation, the new system is installed for a small number of
users. These users learn, use and evaluate the new system. Once the new system is deemed
Adam Florence SDD HSC Notes
15
to
be
performing
satisfactorily
then
the
system
is
installed
and
used
by
all.
This
is
useful
for
new
products,
as
it
ensures
functionality
is
at
a
level
that
can
perform
in
a
real
operational
setting.
The
method
also
allows
a
base
of
users
to
learn
the
new
system.
These
users
can
then
assist
with
the
training
of
others
once
the
system
has
been
fully
installed.
PHASED
The
phased
method
of
installation
from
an
old
system
to
a
new
one
involves
a
gradual
introduction
of
the
new
system
whilst
the
old
system
is
progressively
discarded.
This
can
be
achieved
by
introducing
new
parts
of
the
product
one
at
a
time
while
the
older
parts
being
replaced
are
removed.
Often
phased
conversion
is
used
because
the
product,
as
a
whole,
is
still
under
development.
DIRECT
CUT-OVER
This
method
involves
the
old
system
being
completely
dropped
and
the
new
system
being
completely
installed
at
the
same
time.
The
old
system
is
no
longer
available.
As
a
consequence,
you
must
be
absolutely
sure
that
the
new
system
is
totally
functional
and
operational.
This
method
is
used
when
it
is
not
feasible
to
continue
operating
two
systems
together.
Any
data
to
be
used
in
the
new
system
must
be
converted
and
imported
from
the
old
system.
Users
must
be
fully
trained
in
the
operation
of
the
new
system
before
the
conversion
takes
place.
EMPLOYMENT TRENDS IN SOFTWARE DEVELOPMENT
OUTSOURCING
As the software development industry has matured, businesses specialising in particular
areas of software development have emerged. It is now unusual for businesses to write their
own applications in house, rather, they contract the services of a specialist software
developer, this is known as outsourcing. Software development companies will also
outsource work to specialists if they do not have the expertise or resources internally.
Some reasons why businesses may choose to outsource software development include: to
reduce and control costs; higher quality results from specialists; resources not available
internally; faster development times; and specialists respond better to change.
CONTRACT PROGRAMMERS
The nature of employment in the software development area is changing. Many positions of
employment are short-term contracts to write particular software products. It is common
for analysts and programmers to change employer often as they seek new contracts.
Contracts can be with companies that are writing software for their own, internal use or
with software development companies who are writing software for external customers.
TRENDS IN SOFTWARE DEVELOPMENT
ENVIRONMENT IN WHICH DEVELOPERS WORK
Networks of computers, and in particular the internet, have created a new and growing
environment for software development. Developers from across the globe can collaborate
on software projects. Many open source projects have contributors from a wide range of
countries. Within software development companies, teams of developers work closely
together. They continuously collaborate to produce quality code. In the past each
programmer was given a specific set of programming tasks to complete, today this is rarely
the case, now developers are more than just coders. They are multi-skilled and work
together with other developers and users as the development process progresses.
Adam Florence SDD HSC Notes
16
CHANGING NATURE OF APPLICATIONS
In the past, most software developers where writing applications for desktop computers or
for servers. The recent changes are largely due to the widespread need to continually
update their skills to take account of public demand for internet connected software
applications. Some examples of recent trends include:
Web-based
software
Learning
objects
Widgets
Apps
and
applets
Web
2.0
tools
Cloud
computing
Mobile
phone
technologies
Collaborative
environments
9.2 SOFTWARE DEVELOPMENT CYCLE
9.2.1 DEFINING AND UNDERSTANDING THE PROBLEM
DEFINING THE PROBLEM
Problems can come from a number of different sources. It may be that an outside company
is looking to contract a software developer to construct a solution for their business. It could
be a new idea for a product. In either case, the problem itself needs to be defined precisely
so that both the developer and the client understand what will be done. Some questions
that need to be asked to help define and identify the problem are:
What
are
the
clients
needs
which
this
product
will
meet?
Compatibility
issues
with
other
existing
software
and
hardware?
Possible
performance
issues,
particularly
for
internet
and
graphics
intensive
systems?
What
are
the
boundaries
of
the
new
system?
NEEDS
OF
THE
CLIENT
A
need
is
an
instance
in
which
some
necessity
or
want
exists.
The
implication
is
that
some
form
of
solution
is
required
to
meet
this
need.
Without
articulating
the
needs
clearly,
it
will
be
difficult
to
develop
a
clear
picture
of
the
precise
problem
to
be
solved.
FUNCTIONALITY
REQUIREMENTS
Functionality
requirements
describe
what
the
system
will
do.
They
are
what
you
are
aiming
to
achieve.
Requirements
are
statements
that
if
achieved,
will
allow
needs
to
be
met.
The
requirements
of
a
system
give
direction
to
the
project.
Throughout
the
design
and
development
of
a
system,
the
functionality
requirements
should
continually
be
examined
to
ensure
their
fulfilment.
The
final
evaluation
of
a
projects
success
or
failure
is
based
on
how
well
the
original
requirements
have
been
achieved.
COMPATIBILITY
ISSUES
Software
of
various
types
runs
on
a
variety
of
operating
systems,
browsers,
hardware
configurations
and
even
a
range
of
different
devices,
such
as
smart
phones
and
tablet
computers.
Users
are
able
to
configure
their
device
in
a
variety
of
manners,
for
example
screen
resolution,
colour
depth
and
font
sizes.
Today
many
software
products
require
and
Adam Florence SDD HSC Notes
17
use
internet
or
LAN
connections.
Such
connections
operate
at
varying
speeds
and
will
often
encounter
errors
or
even
complete
loss
of
connectivity.
When
designing
software,
developers
must
ensure
their
products
are
compatible
with
a
wide
range
of
likely
user
devices
and
network
conditions.
Some
examples
of
common
compatibility
issues
include:
Problems with different versions of the intended OS
Not all graphics cards are supported by many graphics code libraries
Screens which do not resize to support different screen resolutions
Labels for screen elements which overlap or are no longer aligned correctly when
fonts are enlarged
Loss of server connection causes fatal errors over wireless networks
Any
existing
hardware,
software
and
communications
systems
must
be
documented
and
the
taken
into
account
when
defining
the
problem
to
ensure
the
solution
will
be
compatible
with
these
existing
resources.
PERFORMANCE
ISSUES
Often
the
specifications
of
the
computers
used
by
developers
far
exceed
those
likely
to
be
present
in
a
typical
users
computer.
In
addition
multi-user
applications
and
applications
that
access
large
files
and
databases
will
perform
very
differently
under
real
world
conditions.
Testing
environments
and
actual
tests
should
simulate
real
world
conditions.
Some
common
examples
of
performance
issues
include:
The
computer
appears
to
be
not
responding
after
some
function
has
been
initiated.
In
fact
it
is
busy
processing
a
time
consuming
task
Users
experience
poor
response
times.
This
is
often
seen
with
networked
applications
where
during
data
entry
users
spend
most
of
their
time
waiting
for
the
application
BOUNDARIES
OF
THE
PROBLEM
Boundaries
define
the
limits
of
the
problem
or
system
to
be
developed.
Anything
outside
the
system
is
said
to
be
a
part
of
the
environment.
The
system
interacts
with
its
environment
via
an
interface.
Input
and
output
to
and
from
the
system
takes
place
via
an
interface.
The
keyboard
provides
an
interface
that
allows
humans
to
input
data
into
a
computer
system.
An
internet
service
provider
provides
an
interface
between
computers
and
the
internet.
It
is
vital
to
determine
the
boundaries
of
a
problem
to
be
solved.
Determining
the
boundaries
is,
in
effect,
determining
what
is
and
what
is
not
part
of
a
system.
When
defining
a
problem
it
is
important
to
define
the
boundaries
for
the
problem
so
that
the
customer
has
realistic
expectations
of
the
limits
of
the
system.
ISSUES RELEVENT TO A PROPOSED SOLUTION
Although a new solution may well meet the current identified needs there are other areas
that should be considered prior to investing time and money in the development of a new
software product. Will a new solution provide enough advantages to the organisation to be
worth the time, effort and money involves in its development and implementation. Points to
consider from the clients perspective: will the existing system be able to perform the
required tasks in the foreseeable future; will the proposed new system meet future needs;
have existing similar solutions been examined; how crucial is the new system to the total
organisation. Points to be considered by the software developer include: what expertise is
required to complete the project; what resources are required to develop this project; will
Adam Florence SDD HSC Notes
18
we
be
able
to
support
this
product
in
the
future;
can
we
redistribute
existing
staff
and
resources
to
this
project.
DETERMINING
IF
AN
EXISTING
SOLUTION
CAN
BE
USED
SOCIAL
AND
ETHICAL
CONSIDERATIONS
Some
social
and
ethical
areas
that
require
consideration
include:
Changing
nature
of
work
for
users-
the
introduction
of
new
software
products
has
an
effect
on
the
nature
of
work
for
users
of
the
system.
We
must
consider
that
effect
the
new
system
will
have
on
the
users,
this
could
include
changing
of
employment
contracts
and
retraining
Effects
on
level
of
employment-
in
many
ways,
computers
have
replacing
the
work
done
by
people.
One
of
the
mains
reasons
for
creating
new
software
is
to
reduce
business
costs,
including
wages.
Hence
software
products
are
designed
to
reduce
the
overall
level
of
employment
in
an
area
Effects
on
the
public-
large
software
systems
can
have
a
substantial
effect
on
the
general
public.
The
introduction
of
ATMs
involves
retraining
the
entire
population.
Many
seniors
were
reluctant
to
make
use
of
this
new
banking
system.
Effects
on
the
public
are
both
positive
and
negative.
It
is
vital
that
consideration
be
given
to
its
effect
on
the
public
LICENSING
CONSIDERATIONS
All
parties
must
consider
issues
related
to
copyright,
both
in
terms
of
protecting
the
rights
of
the
developer
and
the
legal
rights
of
the
customers
who
will
purchase
and
use
the
product.
CUSTOMISATION
OF
EXISTING
SOFTWARE
PRODUCTS
Customisation
of
an
existing
software
product
is
often
a
cost
effective
strategy
for
obtaining
new
functionality.
Many
software
developers
spend
much
of
their
time
modifying
their
own
existing
products
to
suit
the
specific
needs
of
individual
clients.
Open
source
software
is
also
routinely
customised
to
add
new
features.
The
ability
to
customise
software
helps
the
original
developer
of
the
product
widen
their
market.
COST
EFFECTIVENESS
Usually
one
of
the
constraints
of
a
new
software
system
will
be
that
it
falls
within
a
certain
budget.
Once
estimates
and
quotations
have
been
obtained,
an
overall
development
costing
can
be
compiled.
This
total
development
cost
is
then
compared
to
the
allocated
budget
for
the
project
and
the
total
cost
is
assessed.
SELECTING
AN
APPROPRAITE
DEVELOPMENT
APPROACH
If
an
appropriate
existing
solution
cant
be
found
then
new
software
will
need
to
be
developed.
This
may
involve
developing
the
entire
solution
or
it
may
involve
writing
code
to
customise
an
existing
solution.
When
new
software
is
developed,
one
of
the
first
tasks
is
to
identify
a
suitable
software
development
approach.
One
should
consider
each
approachs
strengths
and
weaknesses,
and
should
consider
a
combination
of
approaches
if
appropriate.
DESIGN
SPECIFICATIONS
SPECIFICATIONS
OF
THE
PROPOSED
SOLUTION
Developing
a
set
of
design
specifications
is
one
of
the
most
important
steps
before
the
actual
design
is
planned.
The
design
specifications
form
the
basis
for
planning
and
designing
the
solution.
The
aim
of
the
design
specifications
is
to
accurately
interpret
the
needs,
requirements
and
boundaries
identified
into
a
set
of
workable
and
realistic
specifications
Adam Florence SDD HSC Notes
19
from
which
a
final
solution
can
be
created.
These
design
specifications
should
include
considerations
from
both
the
developers
and
the
users
perspective.
Developers Perspective
Users Perspective
Consideration of:
Consideration of:
Data
types
Data
structures
Algorithms
Variables
Software
design
approach
Quality
assurance
Modelling
the
system
Documentation
Interface
design
Relevance
to
the
users
environment
and
computer
configuration
Social
and
ethical
issues
Appropriate
messages
Appropriate
icons
Relevant
data
formats
for
display
Ergonomic
issues
DEVELOPERS
PERSPECTIVE
These
specifications
will
create
standard
framework
under
which
the
term
of
developers
must
work.
These
are
specifications
that
will
not
directly
affect
the
product
from
the
users
perspective
but
will
provide
a
framework
in
which
the
team
of
developers
will
operate.
The
modelling
methods
will
be
specified.
The
method
and
depth
of
algorithm
description
to
be
used,
how
data
structures,
data
types
and
variable
names
are
to
be
allocated
and
any
naming
conventions
that
should
be
used
should
all
be
specified.
A
system
for
maintaining
an
accurate
data
dictionary
needs
to
be
specified.
In
other
words,
a
framework
for
the
organisation
of
the
development
process
is
set
up
so
that
each
member
of
the
development
team
will
be
creating
sections
of
the
solution
that
look,
fell
and
are
documented
using
a
common
approach.
Once
these
specifications
have
been
developed
a
system
model
can
be
created
to
give
an
overview
of
the
entire
system.
These
system
models
will
lead
to
the
allocation
of
specific
tasks
for
completion
by
team
members,
whilst
at
the
same
time
an
overall
direction
of
the
project
can
be
visualised.
USERS
PERSPECTIVE
Specifications
developed
form
the
users
point
of
view
should
include
any
design
specifications
that
influence
the
experience
of
the
end-user.
Standards
for
interface
design
will
be
specified
to
ensure
continuity
of
design
across
the
projects
screens,
for
example,
user
of
menus,
colour
and
placement.
The
wording
of
messages,
design
of
icons
and
the
format
of
any
data
presented
to
the
user
need
to
be
determined
and
a
set
of
specifications
created,
for
example
font
user
for
prompts
and
user
input,
the
size
of
icons
and
the
tone
of
language
used.
Ergonomic
issues
should
also
be
considered
and
taken
into
account
as
part
of
the
design
specifications.
Consider:
which
functions
will
be
accessed
most?
Which
functions
require
keyboard
shortcuts?
What
is
the
order
in
which
data
will
be
entered?
Are
the
screens
aesthetically
pleasing?
Such
questions
need
to
be
examined
and
a
standard
set
of
design
specifications
generated.
System
models
can
assist
in
determining
user
based
design
specifications,
in
particular,
screen
designs
and
concept
prototypes.
It
is
vital
that
software
developers
acknowledge
the
Adam Florence SDD HSC Notes
20
contribution user make to the development of design specifications. Communications and in
particular feedback form users is especially important at this early stage.
SYSTEM
DOCUMENTATION
RESRESENTING
A
SYSTEM
USING
SYSTEMS
MODELLING
TOOLS
IPO
DIAGRAMS
These
diagrams
are
used
to
document
a
system
by
identifying
the
inputs
into
each
major
process,
the
general
nature
of
these
processes,
and
the
outputs
produced.
The
IPO
diagram
is
in
the
form
of
a
table
with
3
columns,
one
for
Input,
Process
and
Output.
The
following
IPO
diagram
describes
the
voting
system
subsequently
shown
as
a
data
flow
diagram.
CONTEXT
DIAGRAMS
Adam Florence SDD HSC Notes
21
Context
diagrams
are
used
to
represent
an
overview
of
the
system.
The
system
is
shown
as
a
single
process
along
with
the
inputs
and
outputs.
The
external
entities
are
connected
to
the
single
process
by
data
flow
arrows.
Each
elements
represented
is
labelled.
A
context
diagram
does
not
show
data
stores
or
internal
process.
DATA
FLOW
DIAGRAMS
Data
flow
diagrams
represent
a
system
as
a
number
of
processes
that
together
form
a
single
system.
A
data
flow
diagram
is
a
refinement
of
a
context
diagram.
Data
flow
diagrams
therefore
show
a
further
level
of
detail
not
seen
in
the
context
diagram.
Data
flow
diagrams
identify
the
source
of
data,
its
flow
between
processes
and
its
destination
along
with
data
generated
by
the
system.
Adam Florence SDD HSC Notes
22
STORYBOARDS
A
storyboard
shows
the
various
interfaces
(screens)
in
a
system
as
well
as
the
links
between
them.
The
representation
of
each
interface
should
be
detailed
enough
for
the
reader
to
identify
the
purpose,
contents
and
design
elements.
Areas
used
for
input,
output
and
navigation
should
be
clearly
identified
and
labelled.
Any
links
shown
between
interfaces
should
originate
from
the
navigational
element
that
triggers
the
link.
This
storyboard
represents
an
online
voting
system.
Elements
of
each
screen
are
clearly
identified
and
the
links
between
screens
are
clearly
shown.
Adam Florence SDD HSC Notes
23
Adam Florence SDD HSC Notes
24
STRUCTURE
CHARTS
Structure
charts
represent
a
system
by
showing
the
separate
modules
or
subroutines
that
comprise
the
system
and
their
relationship
to
each
other.
Rectangles
are
used
to
represent
modules
or
subroutines,
with
lines
used
to
show
the
connections
between
them.
The
chart
is
read
from
top
to
bottom,
with
component
modules
or
subroutines
on
successively
lower
levels,
indicating
these
modules
or
subroutines
are
called
by
the
module
or
subroutine
above.
For
all
modules
or
subroutines
called
by
a
single
module
or
subroutine,
the
diagram
is
read
from
left
to
right
to
show
the
order
of
execution.
SYSTEM
FLOWCHARTS
System
flowcharts
are
a
diagrammatic
way
of
representing
the
system
to
show
the
flow
of
data,
the
separate
modules
comprising
the
system
and
the
media
used.
Standard
symbols
include
those
used
for
representing
major
processes
and
physical
devices
that
capture,
store
and
display
data.
Many
of
these
symbols
have
become
outdated
as
a
result
of
changes
in
technology.
Note
that
system
flowcharts
are
distinctly
different
from
program
flowcharts,
which
are
used
to
represent
the
logic
in
an
algorithm.
They
do
not
use
a
start
or
end
symbol,
and
are
not
intended
to
represent
complex
logic.
Adam Florence SDD HSC Notes
25
Adam Florence SDD HSC Notes
26
DATA
DICTIONARIES
A
data
dictionary
is
a
comprehensive
description
of
each
data
item
in
a
system.
This
commonly
includes:
variable
name,
size
in
bytes,
number
of
characters
as
displayed
on
screen,
data
type,
format
including
number
of
decimal
places
(if
applicable)
and
a
description
of
the
purpose
of
each
field
together
with
an
example.
ALGORITHMS USED TO DOCUMENT THE LOGIC IN MODULES AND SUBROUTINES
It is expected that students are able to develop and interpret algorithms using pseudocode
and flowcharts. Pseudocode uses English-like statements with defined rules of structure and
keywords. In pseudocode:
Keywords are written in capitals
Adam Florence SDD HSC Notes
27
Structural
elements
come
in
pairs,
e.g.
for
every
BEGIN
there
is
an
END,
for
every
IF
there
is
an
ENDIF.
Indenting
is
used
to
identify
control
structures
in
the
algorithm
The
names
of
subprograms
are
underlined.
This
means
that
when
refining
the
solution
to
a
problem,
a
subroutine
can
be
referred
to
in
an
algorithm
by
underlining
its
name,
and
a
separate
subprogram
developed
to
show
the
logic
of
that
routine.
This
feature
enables
the
use
of
the
top-down
development
concept,
where
details
for
a
particular
process
need
only
be
considered
within
the
relevant
subroutine.
Flowcharts
are
a
diagrammatic
method
representing
algorithms,
which
are
read
from
top
to
bottom
and
left
to
right.
Flowcharts
use
the
following
symbols
connected
by
lines
with
arrowheads
to
indicate
the
flow.
It
is
common
practice
to
show
arrowheads
to
avoid
ambiguity.
Flowcharts
using
these
symbols
should
be
developed
using
only
the
standard
control
structures
(described
on
the
following
pages).
It
is
important
to
start
any
complex
algorithm
with
a
clear,
uncluttered
main
line.
This
should
reference
the
required
subroutines,
whose
detail
is
shown
in
separate
flowcharts.
A
subroutine
should
rarely
require
more
than
one
page,
if
it
correctly
makes
use
of
further
subroutines
for
detailed
logic.
SEQUENCE
BINARY SELECTION
Adam Florence SDD HSC Notes
28
MULTI-WAY SELECTION
REPETITION: PRE-TEST
REPETITION:
POST-TEST
REPETITION: COUNTED LOOP
Adam Florence SDD HSC Notes
29
SUBPROGRAM
TEST
DATA
AND
EXPECTED
OUTPUT
Developing
suitable
test
data
to
ensure
the
correct
operation
of
algorithms
is
an
important
aspect
of
algorithm
development.
Test
data
should
test
every
possible
route
through
the
algorithm
as
well
as
testing
each
boundary
condition.
Testing
each
route
makes
sure
that
all
statements
are
correct
and
that
each
statement
works
correctly
in
combination
with
every
other
statement.
Testing
boundary
conditions
ensures
that
each
decision
is
correct.
Commonly,
a
decision
will
be
out
by
1
as
a
result
of
an
incorrect
operator,
for
example
<
instead
of
<=.
When
designing
test
data
it
must
take
into
account
the:
Legal
and
expect
values:
i.e.
critical
values
(values
which
a
condition
is
based
on)
and
boundary
values.
Legal
but
unexpected
values:
i.e.
data
in
an
incorrect
format
(e.g.
decimal)
but
accepted
by
the
programs
guidelines.
Adam Florence SDD HSC Notes
30
Illegal
but
expect
values:
i.e.
illegal
data
due
to
ignorance,
typing
errors
or
poor
instructions.
These
errors
should
be
trapped
and
not
halt
the
execution
of
the
program.
When
initial
test
data
items
are
created
the
expected
output
from
these
inputs
should
be
calculated
by
hand.
Once
the
subroutine
has
been
coded,
the
test
data
is
entered
and
the
output
from
the
subroutine
is
compared
to
the
expected
outputs.
If
the
actual
and
expected
outputs
match
then
this
provides
a
good
indication
that
the
subroutine
works.
If
they
dont
then
clearly
a
logic
error
has
occurred.
Further
techniques
must
be
employed
to
determine
the
source
of
the
error.
COMMUNICATION ISSUES BETWEEN CLIENT AND DEVELOPER
THE NEED EMPOWER THE CLIENT DURING THE DEVELOPMENT PROCESS
It is important to keep the user involved in the software development cycle. Listening is an
important skill for developers. Best for the developer to provide a range of possible
alternatives with good functional features than for the user to come up with their own
design. The end result must satisfy the users needs, the users will decide this.
THE NEED TO CONSULT WITH THE CLIENT
The user is not interested in how the task is achieved, but more on the finished product.
User doesnt need to know the technical details. If a user comes up with an idea that will
make the tasks more comfortable and productive then it is worth considering. The user
needs all tasks that they specified to run as smooth as possible and most efficiently.
THE NEED TO INCORPORATE THE CLIENTS PERSPECTIVE
It is important for the software developer to continually use verbal and written contact with
the user to clarify needs and the purpose of the program. It is far cheaper to solve problems
at this stage. Surveys, questionnaires, interviews, observation and prototypes are all ways of
gathering feedback to help the developer clarify needs.
9.2.2 PLANNING AND DESIGNING SOFTWARE SOLUTIONS
STANDARD ALGORITHMS
STANDARD LOGIC USED IN SOFTWARE SOLUTIONS
FINDING MAXIMUM AND MINIMUM VALUES IN ARRAYS
Adam Florence SDD HSC Notes
31
PROCESSING STRINGS
Adam Florence SDD HSC Notes
32
GENERATING
A
SET
OF
UNIQUE
RANDOM
NUMBERS
Adam Florence SDD HSC Notes
33
PROCESSING OF SEQUENTIAL FILES
Adam Florence SDD HSC Notes
34
PROCESSING
OF
RELATIVE
FILES
Adam Florence SDD HSC Notes
35
Adam Florence SDD HSC Notes
36
LINEAR SEARCH
BINARY
SEARCH
Adam Florence SDD HSC Notes
37
BUBBLE
SORT
Adam Florence SDD HSC Notes
38
SELECTION SORT
Adam Florence SDD HSC Notes
39
INSERTION
SORT
Adam Florence SDD HSC Notes
40
CUSTOM-DESIGNED LOGIC USED IN SOFTWARE SOLUTIONS
USE OF DATA STRUCTURES
ARRAYS
A simple array is a grouped list of similar variables, all of which are used for the same
purpose and are of the same data type.
Individual elements are accessed using an index, which is a simple integer variable.
Before using an array in a program, some languages first require that it must be
dimensioned (that is, defined) in order to allocate sufficient memory for the specified
number of elements. A statement such as the following is a typical example of the required
code: DIM Names (20) as string.
MULTI-DIMENSIONAL ARRAYS
Arrays can be of many dimensions. A useful way to diagrammatically represent a
multidimensional array is to think of each element being further subdivided with each
successive dimension. Individual elements are accessed using one index for each dimension,
each of which is a simple integer variable.
Consider a 3-dimensional array Sales (Town, Month, Product) that stores information about
sales of four different products in each month for a number of towns.
Before using a multi-dimensional array in a program, some languages require that it must
first be dimensioned (defined) in order to allocate sufficient memory for the specified
number of elements.
A statement such as the following is a typical example of the required code: DIM Sales (6,
12, 4) as integer
Adam Florence SDD HSC Notes
41
RECORDS
A
record
is
a
grouped
list
of
variables,
which
may
each
be
of
different
data
types.
Individual
elements
are
accessed
using
their
field
names
within
the
record.
Before
using
a
record
in
a
program,
most
languages
require
that
the
record
first
be
dimensioned
(that
is,
defined)
as
a
record
type
to
specify
the
component
field
names
and
data
types.
If
the
component
fields
within
the
record
are
strings,
their
length
must
also
be
specified.
In
the
following
example,
a
Product
record
called
ProdRec
is
defined
to
contain
ProdNum,
description,
quantity
and
price.
A
statement
such
as
the
following
is
a
typical
example
of
the
required
code.
Although
it
is
not
mandatory
to
include
such
a
definition
in
an
algorithm,
students
may
find
it
beneficial
to
include
a
relevant
diagram,
such
as
the
one
below,
to
help
clarify
their
thinking.
ARRAY
OF
RECORDS
An
array
of
records
is
an
array,
each
element
of
which
consists
of
a
single
record.
The
fields
in
that
record
may
be
of
different
data
types.
Every
record
in
the
array
must
have
the
same
structure,
which
is
the
same
component
fields
in
the
same
order.
Before
using
an
array
of
records
in
a
program,
most
languages
require
that
it
must
first
be
dimensioned
in
order
to
allocate
sufficient
memory
for
the
specified
number
of
elements.
This
includes
defining
the
record
type
to
specify
the
component
fields
as
in
the
simple
records.
Adam Florence SDD HSC Notes
42
The
array
of
records
can
then
be
defined
as
an
array
where
each
element
is
defined
as
one
of
these
records.
In
the
following
example,
an
array
of
records
consisting
of
20
such
records
is
defined:
DIM
ProdArrayofRecords
(20)
as
TYPE
ProdRec
Although
it
is
not
mandatory
to
include
such
a
definition
in
an
algorithm,
students
may
find
it
beneficial
to
include
a
relevant
diagram,
such
as
the
one
below,
to
help
clarify
their
thinking.
FILES
A
file,
in
terms
of
software
development,
means
a
collection
of
data
that
is
stored
in
a
logical
manner.
Normally,
files
are
stored
on
secondary
storage
devices,
usually
a
hard
disk
that
is
Adam Florence SDD HSC Notes
43
separate
from
the
application
program
itself.
There
are
essentially
two
methods
of
storing
and
accessing
data
in
a
file:
sequential
files;
relative
(random
access)
files.
SEQUENTIAL
FILES
Data
is
stored
in
sequential
files
in
a
continuous
stream.
The
data
must
be
accessed
from
beginning
to
end.
An
audiocassette
is
a
sequential
storage
medium
for
audio
data.
To
play
the
third
track
on
an
audiocassette
requires
fast
forwarding
through
tracks
one
and
two.
Sequential
files
operate
in
the
same
manner.
To
access
data
stored
in
the
middle
of
a
sequential
file
requires
reading
all
the
preceding
data.
The
data
stored
in
a
sequential
file
may
have
some
structure,
however
the
structure
is
not
stored
as
part
of
the
file.
Applications
that
access
sequential
files
must
know
about
the
structure
of
the
file.
Text
files
are
sequential
files;
the
data
within
the
text
file
is
merely
a
collection
of
ASCII
or
Unicode
characters.
When
using
sequential
files
it
is
necessary
to
structure
the
data
yourself.
Sentinel
values
(dummy
value
to
indicate
the
end
of
data
within
a
file)
can
be
used
to
indicate
logical
breaks
in
the
data
and
also
to
indicate
the
end
of
the
file.
For
example,
tab
characters
may
be
used
between
fields
and
carriage
return
characters
between
records.
Often
a
particular
string,
such
as
ZZZ,
may
be
used
as
a
sentinel
to
indicate
the
end
of
a
sequential
file.
When
sentinel
value
is
used
to
signal
the
end
of
a
file
car
is
required
to
ensure
the
sentinel
value
is
not
processed
as
if
it
were
data.
When
reading
sequential
files
it
is
common
to
use
an
initial
or
priming
read
before
the
main
processing
loop
to
detect
files
which
only
contain
the
sentinel.
Many
programming
languages
include
their
own
commands
for
writing
to
and
reading
from
sequential
files.
These
commands
operate
well
when
the
file
will
only
be
accessed
using
the
inbuilt
commands.
For
instance
the
languages
write
command
is
used
to
create
files
and
the
languages
read
command
is
used
to
get
data
from
the
file.
Essentially
the
format
of
the
text
file
is
defined
and
determined
by
the
languages
commands
and
the
programmer
is
relieved
of
much
of
the
detailed
work.
Sequential
files
can
be
opened
in
one
of
three
modes
input,
output
and
append.
Input
is
used
to
read
the
data
within
the
file,
output
is
used
to
write
data
to
a
new
file
and
append
is
used
to
write
data
commencing
at
the
end
of
an
existing
file.
Notice
it
is
generally
not
possible
to
commence
writing
from
the
middle
of
an
existing
sequential
file.
This
is
because
the
length
of
data
items
within
the
file
is
unknown
and
hence
there
is
no
way
to
ensure
required
data
is
not
overwritten.
Relative
files
overcome
this
restriction.
RELATIVE
(OR
RANDOM
ACCESS)
FILES
Relative
refers
to
the
fact
that
there
is
a
known
structure
to
these
files,
which
allows
the
start
of
individual
records
to
be
determined.
As
each
record
within
the
file
is
exactly
the
same
length
then
the
relative
position
of
each
record
within
the
file
can
be
used
to
access
individual
records.
In
effect
the
position
of
each
record
in
the
file
is
used
as
a
key
to
allow
direct
access
to
each
record.
For
example,
if
records
are
30
bytes
long,
then
the
100th
record
will
commence
after
the
3000th
byte
in
the
file.
Random
access
refers
to
the
ability
to
access
records
in
any
order.
Unlike
sequential
files,
it
is
possible
to
read
the
10th
record,
then
the
2nd
record,
and
then
the
50th
record
and
so
on
in
any
desired
random
order.
With
sequential
files
we
must
read
from
the
starts
of
the
file
through
to
the
end
of
the
file,
hence
if
we
require
the
100th
record
we
must
first
reach
each
of
the
preceding
99
records.
Furthermore
when
writing
data
we
are
able
to
edit
or
update
individual
records
within
a
file,
which
was
not
possible
using
sequential
files.
Adam Florence SDD HSC Notes
44
Random
access
or
relative
files
can
be
likened
to
CDs.
With
a
music
CD,
individual
tracks
can
be
played
in
any
order.
Many
CD
players
include
a
random
function
whereby
tracks
are
played
in
a
random
order.
The
structure
of
an
audio
CD
is
stored
on
the
CD.
If
you
wish
to
play
track
five,
the
laser
head
jump
directly
to
the
start
of
track
five.
Random
access
files
allow
individual
data
items
to
be
accessed
directly
without
the
need
to
read
any
of
the
preceding
data.
In
fact
random
access
files
are
often
known
as
direct
access
files.
Relative
files
are
used
to
store
records.
Each
record
is
the
same
data
type
and
must
be
of
precisely
the
same
length.
Complete
records
are
read
and
written
to
relative
files.
The
programming
language
is
able
to
determine
the
precise
byte
where
a
record
begins
because
all
records
are
the
identical
length.
Individual
fields
within
records
can
be
identified
precisely
because
the
exact
length
and
structure
of
each
record
is
known.
Fields
containing
strings
that
are
of
differing
lengths
are
usually
padded
out
using
the
blank
character
(ASCII
code
32).
CUSTOMISED
OFF-THE-SHELF
PACKAGES
Customisation
of
an
existing
software
product
is
often
a
cost
effective
strategy
for
obtaining
new
functionality.
Many
software
developers
spend
much
of
their
time
modifying
their
own
existing
products
to
suit
the
specific
needs
of
individual
clients.
For
example,
Parramatta
Education
Centre
writes
custom
database
applications
often
using
Microsoft
Access
to
build
the
data
entry
forms
and
printed
reports.
Much
of
the
routine
work
performed
by
the
company
involves
upgrading
existing
product
to
include
additional
features.
In
this
case
Microsoft
Access
is
being
used
to
create
and
update
different
COTS
products.
Open
source
software
is
also
routinely
customised
to
add
new
features.
For
example,
phpBB
is
a
popular
open
source
product
used
to
build
online
forums.
Many
of
the
forums
based
on
phpBB
have
been
customised
to
suit
the
unique
requirements
of
particular
forums.
In
many
cases
the
modifications
are
built
as
add-ons,
which
are
then
made
available
to
other
users
of
the
base
software
product.
For
example,
an
add-on
for
phpBB
awards
points
to
users
based
on
the
number
and
quality
of
posts
they
make.
Other
add-ons
allow
paid
advertisements
relevant
to
the
sub
form
being
viewed,
to
be
embedded
within
screens.
The
ability
to
customise
software
helps
the
original
developer
of
the
product
widen
their
market.
It
is
now
common
for
tools
to
be
included
in
many
commercial
products
that
allow
the
end
user
to
create
customised
screens
and
other
functionality
through
the
use
of
wizards
and
various
drag
and
drop
design
screens.
Other
companies
who
specialise
in
software
for
particular
industries
offer
their
own
software
customisation
service.
For
example,
GeoCivil
is
a
software
product
designed
for
use
by
civil
engineers.
The
developers
offer
a
customisation
service
where
GeoCivil
can
be
altered
to
suit
particular
requirements.
STANDARD MODULES (LIBRARY ROUTINES) USED IN SOFTWARE SOLUTIONS
REQUIREMENTS FOR GENERATING A MODULE OR SUBROUTINE FOR RE-USE
IDENTIFICATION OF APPROPRIATE MODULES
Factors the include the appropriate use of modules include:
Thorough documentation including intrinsic naming of variables and objects
Standard control structures are utilised
Choice of language suits the modules
Social and ethical issues related to the module
Modules that contain standard and redundant tasks will only waste memory
APPROPRIATE TESTING USING DRIVERS
Adam Florence SDD HSC Notes
45
Drivers
are
temporary
code
used
to
test
the
execution
of
a
module
when
the
module
cant
function
individually
without
a
mainline.
Drivers
pass
values
to
and
from
the
subprogram.
Drivers
need
to
be
used
to
test
the
module
before
becoming
a
standard
module.
THOROUGH
DOCUMENTATION
Documentation
must
be
included
with
any
project
and
aspect
of
a
program.
This
leads
to
successful
teamwork
and
new
members
can
be
hired
and
understand
whats
going
on.
Every
programmer
needs
to
understand
the
processes
of
a
module
if
they
are
to
successfully
use
or
modify
a
module.
Documentation
must
also
include
the
author,
date,
purpose
and
nature
of
parameters
used.
ISSUES
ASSOCIATED
WITH
RE-USABLE
MODULES
Issues
include:
Identifying appropriate modules
Considering local and global variables
Appropriately using parameters
INTERFACE
DESIGN
CONSIDERATION
OF
INTENDED
AUDIENCE
The
user
interface
needs
to
be
designed
to
suit
the
intended
audience.
A
product
written
for
pre-school
children
will
require
quite
a
different
interface
to
a
product
design
to
perform
complex
calculation
for
engineers.
An
accounting
product
designed
for
use
by
accountants
can
use
the
jargon
of
the
finance
world.
A
similar
package
designed
for
the
general
public
should
not
use
jargon.
Systems
intended
for
large
audiences
with
unknown
levels
of
expertise
may
include
user
interfaces
that
can
be
personalised.
For
example,
IBMs
OS400
OS
provides
help
on
error
messages
at
three
user-defined
levels:
beginner,
intermediate
and
advanced.
The
wording
of
error
messages
changes
appropriately.
IDENTIFICATION
OF
DATA-FIELDS
AND
SCREEN
ELEMENTS
Before
the
task
of
designing
a
user
interface
can
commence
the
data
to
be
included
on
each
screen
needs
to
be
determined.
The
system
models,
algorithms
and
data
dictionaries
will
provide
this
information.
Once
the
required
data
is
ascertained
the
next
task
is
to
decide
on
the
most
effective
screen
element
to
use
to
display
each
data
item.
Some
common
screen
elements
in
terms
of
the
data
type
they
best
represent
include:
Menus- used to initiate execution of particular modules within a program. Drop-
down menus are used in most GUI based products. Often the items on the menus of
a project will correspond to the calls to sub-programs in the mainline of the source
code. E.g. file, edit, view etc.
Command buttons- used to select a different path for execution. Often command
buttons are used to confirm a task should take place. E.g. OK and cancel.
Tool bars- used to quickly access commonly used items. Each tool is represented as
an icon. The functions available from tool bars are generally also available via the
menus
Text boxes- used to receive input in the form of strings. They provide no included
mechanisms for validating the data entered, e.g. number is entered as string
List boxes- used to enable the user to select from the given options. This screen
element is self-validating as it is not possible for the user to enter unexpected input.
Adam Florence SDD HSC Notes
46
List
boxes
can
be
configured
to
allow
multiple
selections.
The
options
can
be
loaded
from
an
array
or
input
by
programmer
Combination
boxes-
used
to
combine
the
functions
of
a
text
box
and
list
box.
A
text
box
is
provided
for
keyboard
entry
or
the
user
can
select
an
item
from
the
list
box.
They
are
able
to
force
input
of
one
of
the
items
in
the
list.
They
can
also
be
set
so
that
new
items
entered
become
part
of
the
list
Check
boxes-
used
to
obtain
Boolean
input
from
the
user.
This
is
a
self-validating
screen
element
Radio
or
option
buttons-
user
to
force
the
user
to
select
one
of
the
displayed
buttons.
It
is
not
possible
to
select
more
than
one
option.
Only
used
when
a
small
number
of
possible
options
are
available,
because
they
use
a
lot
of
space
Scroll
bars-
used
to
display
the
position
of
a
numeric
data
value
within
a
given
range.
Often
used
to
navigate
within
another
element,
e.g.
list
boxes.
Scroll
bars
give
the
user
a
visual
interpretation
of
their
position
relative
to
the
starts
and
end
of
the
range
of
possible
values
Grids-
used
as
a
two-dimensional
screen
element
that
can
be
likened
to
an
array
of
records.
Rows
can
be
records
and
columns
can
be
fields.
Each
cell
is
a
text
box.
Labels-
used
to
provide
information
and
guidance
to
the
user.
Often
provide
instruction
to
users
in
regard
to
required
input
into
other
screen
elements
Picture
boxes-
used
to
display
graphics
FACTORS CONSIDERED WHEN SELECTING PROGRAMMING LANGUAGE
The most appropriate programming language should be selected after considering each of
the following criteria:
Sequential or event-driven: Event-driven languages allow the user to choose the
order in which processing occurs, e.g. a word processor, as the user decides the
order of tasks to be accomplished. Sequential languages ensure that the software
executes in a distinct order, e.g. in the game of snap, the rules must be played in a
sequence
Required features: the reason so many languages exist is that solutions to different
problems require different features within languages. Careful consideration of
features required to implement a solution will results in reduced development times
and more efficient products
Hardware and OS ramifications: many programming languages are designed for
particular OSs. As OSs are specific to particular types of hardware, the programming
language selected will most likely have hardware ramifications
Language chosen will determine the following factors:
The type of solution to be designed (complexity)
Type of hardware that will execute the problem
Peripheral devices used (mouse, keyboards, printers)
The existence of library routines available
The designated target user (professionals or general public)
FACTORS CONSIDERED WHEN SELECTING TECHNOLOGY
PERFORMANCE REQUIREMENTS
Comparing the performance of different hardware components, such as different CPUs or
different HDDs is a difficult task. There are many factors that should be considered and not
all factors will be relevant for all systems. Performance is not just about speed, but also the
Adam Florence SDD HSC Notes
47
fault
of
tolerance
for
the
device.
A
fast
device
that
fails
within
weeks
is
a
poor
performer.
Can
it
recover
from
power
spikes
and
failures?
When
occurs
when
the
device
is
under
load?
The
specific
performance
requirements
should
be
established
so
that
tests
can
be
developed
to
ensure
these
requirements
are
met.
BENCHMARKING
Benchmarking
is
the
process
of
evaluating
something
by
comparing
it
to
an
established
standard.
Benchmarking
enables
competing
product
to
be
fairly
compared.
For
computers,
software
and
computer
components,
standards
are
commonly
developed
which
assess
performance
requirements
found
to
be
important
by
many
users.
For
example,
the
ability
to
render
3D
graphics
in
HD
at
a
particular
speed
would
be
a
relevant
performance
requirement
for
gamers.
A
standard
to
assess
this
requirement
might
specify
a
particular
game
or
utility,
which
should
be
executed
whilst
the
computer
is
also
running
a
browser.
Often
benchmarking
software
is
able
to
record
technical
details
of
the
variables
in
question
so
that
a
fair
mathematical
and
statistical
evaluation
can
be
made.
9.2.3 IMPLEMENTATION OF SOFTWARE SOLUTIONS
LANGUAGE SYNTAX REQUIRED FOR SOFTWARE SOLUTIONS
The syntax of a programming language refers to the rules that govern the way that the
elements of the language can be joined together to form valid statements.
A computer language needs to be defined precisely because unlike a speaking language, it
must be unambiguous. A Meta language is used to represent the syntax of a programming
language. They are used to describe the rules of programming languages.
EBNF
Extended Backus-Naur notation describes repetition elements in a language.
Symbol Definition
Example
Is defined as
Letter = A|B|C
Or
A|B|C
< >
A language element still to be defined
<Letter>
{ }
Repeated elements enclosed in braces, (repeated 0
or more times)
Word={<letter>}
[ ]
Optional elements
[<Digit>]
( )
Grouped elements
({<Digit>})
Examples:
-
Letter
=
A|B|C
Digit
=
0|1|2|3|4
Identifier
=
<Letter>{<Letter>|<Digit>}
Expression
=
<Identifier>(<Identifier>|<Digit>){<Letter>}
RAILROAD
DIAGRAMS
Railroad
diagrams
are
a
graphical
method
used
to
define
the
syntax
of
a
programming
language.
Adam Florence SDD HSC Notes
48
Rectangles
are
used
to
enclose
non-terminal
symbols,
symbols
that
will
be
further
defined.
Circles
or
rounded
rectangles
are
used
to
enclose
terminal
symbols,
items
that
dont
need
to
be
further
defined.
Paths
to
show
all
valid
combinations
link
these
elements.
Examples:
-
Identifier:
Assignment
Statement:
THE NEED FOR TRANSLATION TO MACHINE CODE FROM SOURCE CODE
TRANSLATION METHODS IN SOFTWARE SOLUTIONS
Translation is the process of converting high-level code or source code into machine
executable code, and then executing it. High-level languages cant be understood directly by
computers, they need to be converted to a form that is understood by the processor. This is
like speaking German to an English speaker. The German needs to be translated into English
before being understood.
COMPILATION
The source code is translated into executable code. The executable code can later be
executed without any need for the translator. Compilation is a batch process. The input to
this process is the high-level source code and the output is the executable file or files. All
coding errors are reported at the end of an unsuccessful compilation operation.
The operation of a compiler is likened to a translator, translating a book into English from
German. The translator will translate the entire text of the novel. Once the manuscript in
English has been produced in its entirety, it is printed and distributed. If the translator cant
understand a sentence in the book, the translator would make notes of these sentences. At
the end of the translation process, these sentences would be analysed and perhaps the
original meaning would be acquired from the author.
Advantages
Disadvantages
- Runs
faster
- Programs
are
usually
smaller
- Programs
are
harder
to
reverse
engineer
or
change
because
the
source
code
is
hidden
from
view
- Run-time errors are not found until
the whole program has been
compiled
- If the program needs modifying, it
must be re-tested and re-compiled
INTERPRETATION
Each
line
of
source
code
is
translated
into
machine
code
and
then
immediately
executed.
If
errors
exist
in
the
source
code,
they
will
cause
a
halt
to
execution
once
encountered
by
the
interpreter.
Adam Florence SDD HSC Notes
49
If
the
German
speaker
and
English
speakers
are
having
a
conversation,
the
speech
interpreter
translates
each
sentence
into
English
as
it
is
spoken
in
German.
If
the
speech
interpreter
cant
understand
a
German
sentence,
he
is
unable
to
translate
it
into
English.
So
the
German
sentence
must
be
altered
so
the
interpreter
can
understand.
Advantages
Disadvantages
- Easy implementation of source
- Execution time is much slower in
code level debugging operations
complex language programs as
because syntax errors are found at
statement decoding becomes
the time that the particular line is
bottleneck
translated and executed
- Code is more easily accessed for
- Run-time and logic errors become
illegal use by other programmers
evident as they are found during
- Programs are generally larger
testing and more easily corrected
- Interpreters allow the program to
add stubs, flags or variable output
statement for debugging, which can
be easily removed when testing and
modification is complete
INCREMENTAL INTERPRETATION
A hybrid between interpretation and compilation, where some frequently used sections of
the program are translated into machine code and stored. The program is then translated
using an interpreter until the compiled sections are reached. These sections are then
executed from the object code in memory. This system is faster, but retains some of the
advantages of interpretation.
STEPS IN TRANSLATION PROCESS
Translating source code into object code
is the major task of the compiler. This
process requires:
Lexical
analysis
Syntactical
analysis
Code
generation
LEXICAL
ANALYSIS
Lexical analysis is the process of
examining each word to ensure it is a
valid part of the language. In terms of
source code translation, lexical analysis
is a process that ensures all reserved
words, identifiers, constants and
operators are legitimate members of
the high-level languages lexicon (dictionary with the vocabulary of a particular language or
subject). At this stage, we are not interested in whether these language elements are in a
sensible order, just to ensure that each is a legitimate language element, on its own.
This is achieved with a table of tokens. This table will initially contain all the reserved words
and operators that are included elements of the language. As lexical analysis continues,
identifiers and constants will be added to the symbol or token table. This table becomes a
Adam Florence SDD HSC Notes
50
dictionary
or
lexicon
for
the
lexical
analysis
process.
Each
character
in
the
source
code
is
read
sequentially.
Once
a
string
of
characters,
matches
an
element
in
the
symbol
table,
it
is
replaced
by
the
appropriate
token.
SYNTACTICAL
ANALYSIS
Syntactical
analysis
is
the
process
of
checking
the
syntax
of
sentences
and
phrases
is
correct
in
terms
of
the
grammatical
rules
of
the
language.
The
second
part
of
syntactical
analysis
is
checking
the
type
of
identifiers
and
constants
used
in
statements
are
compatible.
Parsing
is
the
process
of
checking
the
syntax
of
a
sentence.
A
parse
tree
is
used
to
diagrammatically
describe
the
component
parts
of
a
syntactically
correct
sentence.
Syntactical
analysis
makes
use
of
parse
trees
to
check
each
statement
against
the
precise
description
of
the
syntax.
The
series
of
tokens
delivered
for
syntactical
analysis
is
constructed
into
a
parse
tree
based
on
the
rules
of
the
particular
language
describe
in
EBNF.
Each
statement
in
a
programming
language
will
have
exactly
on
parse
tree,
resulting
in
one
precise
meaning.
If
a
particular
component
of
the
source
code
cant
be
parsed
then
an
error
message
is
generated.
These
error
massages
as
a
result
of
parsing
will
always
be
from
incorrect
arrangement
of
tokens.
CODE
GENERATION
If
the
processes
of
lexical
and
syntactical
analysis
have
completed
without
error,
then
the
machine
code
can
be
generated.
This
stage
involves
converting
each
token
or
series
of
tokens
into
their
respective
machine
code
instructions.
As
it
is
known
that
the
tokens
are
correct
and
in
the
correct
order,
no
errors
will
be
found
during
code
generation.
The
parse
tree
created
during
syntactical
analysis
will
contain
the
tokens
in
their
correct
order
for
code
generation.
The
code
generation
process
traverses
the
parse
tree,
usually
from
left
to
right
along
the
lower
branches.
Tokens
are
collected
and
converted
into
their
respective
machine
code
instructions
as
the
transversal
occurs.
THE ROLE OF MACHINE CODE IN THE EXECUTION OF A PROBLEM
MACHINE CODE AND CPU OPERAITON
Registers are temporary storage holding areas located on the CPU. They store address
location for instructions, results of calculations and flags, which show the result of a
comparison. There are many registers within the CPU. The accumulator is a general-purpose
register used to accept the result of computations performed by the ALU (arithmetic and
logic unit, part of the central processing unit capable of mathematical and logical
operations). It holds the data items currently being processed.
Instructions are made up of 32 bit strings or 64 bit strings, each instruction is made up of 3
parts: opcode (the instruction, telling the processor what to do e.g. copy), first operand
(memory address of where the data is to be stored), second operand (the data). E.g. the
whole instruction could be written as: Copy the memory location specified by the byte of
data represented by 10000001.
Adam Florence SDD HSC Notes
51
Each machine language instruction activates a microcode procedure requiring execution of
one or more microcode instructions. Each microcode instruction is executed using the fetch-
execute cycle.
The program counter is a register that stores the address of the next executable instruction.
It is automatically incremented when an instruction is executed.
A complete fetch execute cycle is required to execute each microcode instruction. The
following steps form this cycle:
1. Fetch. The control unit fetches the instruction from RAM. The control unit does this
by using the program counter to store the memory address for the next instruction
to be carried out. The program counters job is to obtain and store the next
instruction for the CPU
2. Decode. The opcode is separated
from the data addresses by the
control unit. The control unit uses
this opcode to figure out what
type of instruction has to be
carried out. The opcode is then
loaded into the instruction
register, and the data address is
copied into the address register
3. Execute. The opcode in the
instruction register is sent to and
then executed by the ALU
4. Store. While the instruction is
being executed, the results of any data being processed are stored in the
accumulator. The results from the accumulator are then stored in registers or RAM.
The CPU is now ready for the next instruction.
EXECUTION OF CALLED ROUTINES
Commands to be executed are stored with the operation code in the computer's RAM. Each
memory address is accessed sequentially unless the instruction is to jump to another part of
the program. The stack is a special register that keeps record of where the CPU is up to in
the current operation it is carrying out. The stack is important as it keeps track/a list of what
process the CPU is up to. If the CPU needs to re-check the memory address of the current
item being processed, it can look into the stack and retrieve the current address, a program
counter would not do this, as it has already dumped the current address and loaded the next
instruction address.
LINKING, INCLUDING USE OF DLLS
Subprograms are special functions called from the mainline to perform one specific task.
There are three types of subprograms
1. Individually made by a programmer to be used within one application such as a
game. A high score subprogram is used to calculate and store a new high score.
2. Subprograms included within a programming language development package. These
subprograms form part of a library and can be accessed by programmers to perform
simple tasks quicker. The programmer does not need to re-write a subprogram.
Instead the programmer just calls it from the development library. E.g. to randomise
numbers, a function can be called.
3. Subprograms built in to the operating system. The programmer is able to use
subprograms from the operating system. This creates universal features such as the
Adam Florence SDD HSC Notes
52
save
and
print
commands
which
we
see
in
almost
every
word
processing
application.
Even
the
user
interface
is
using
re-used
subprograms
to
create
the
same
interface
such
as
the
minimise,
maximise
and
close
buttons
on
every
application
window.
A
linker
is
the
process
by
which
subprograms
are
joined
to
the
mainline
of
the
program.
A
linker
handles
the
call
and
return
processes.
It
calls
the
subprogram,
gives
it
control
then
returns
control
to
the
mainline
after
it
has
executed.
Dynamic
link
libraries
are
files
containing
object
code
subroutines
that
add
extra
functionality
to
a
high-level
language.
DLLs
are
common
subprograms
used
to
reduce
the
need
for
multiple
subprograms.
DLLs
can
be
called
from
many
different
applications
and
used
by
the
application. If
a
new
program
is
installed
with
a
newer
version
of
the
DLL
then
it
overwrites
the
old
version.
All
other
programs
then
have
to
use
this
newer
version
of
the
DLL.
TECHNIQUES USED IN DEVELOPING WELL-WRITEN CODE
THE USE OF GOOD PROGRAMMING PRACTICE
A CLEAR MAINLINE
Software projects should e developed using a clear modular approach. This refers to the top-
down design of the project. Structure charts can be used to clearly describe the top-down
design. It is important for programmers to adhere to the modular structure indicated on
system models and in algorithms. As a result, the identification of the module where an
error has occurred is simplified.
In general, the mainline should be clear and uncluttered so it is easy to follow and identify
calls to subroutines. Each subroutine in a well-structured program can be coded
independently. The subroutine van be tested and any errors encountered correct. This
system of subroutine creation and testing ensures quality code that is reusable in future
projects.
ONE LOGICAL TASK PER SUBROUTINE
A good way of ensuring each subroutine contains only one logical task is to examine the
name of the routine. A short succinct name should be able to describe the processing
occurring within the subroutine. The algorithm for the subroutine should fit comfortably on
a page. When algorithms become longer then they become difficult to understand and
hence debug and maintain.
APPROPRIATE USE OF CONTROL AND DATA STRUCTURES
Control structures, in particular selection and repetition should only use recognised
statements such as loops. The condition for the loop should determine the only exit from
the loop. There should not be unconditional jumps, which cause control to exit a loop or
selection unexpectedly. The use of pseudocode when writing algorithms ensures only
correct control structures can be used, whereas flowcharts allow flow lines to be drawn in
non-standard ways.
Care is required when designing and coding repetition structures. Programmer should
consider unusual cases such as reading an empty file, processing sentinel values and reacting
to unexpected inputs so that infinite loops or other errors do not occur. The data types of
variables should also be considering when designing terminating conditions. If a loop should
end once a counter exceeds a value it is better to use > or < operators, rather than = as some
floating point values cant be represented exactly and hence an = condition may never be
met.
Adam Florence SDD HSC Notes
53
Data
structures
should
be
selected
and
designed
to
assist
the
processing
to
be
performed.
For
example,
a
program
stores
and
processes
customer
details
including
first
name,
surname,
and
phone,
then
the
programmer
could
use
four
simple
parallel
arrays,
for
each
field
or
they
could
define
a
record
structure
and
then
an
array
of
the
records.
WRITING
FOR
SUBSEQUENT
MAINTENANCE
Coding
should
be
done
in
such
a
way
that
future
maintenance
programmers
could
easily
update
the
code
as
new
requirements
come
to
light.
All
the
points
mentioned
above
will
help
to
simplify
the
tasks
of
maintenance
programmers.
Clear
documentation
within
the
code,
such
as
comments,
appropriate
identifier
names
and
indenting
will
make
understanding
the
logic
of
the
code
clear.
If
a
constant
value
is
to
be
used
throughout
the
code,
it
should
be
assigned
to
an
identifier.
The
identifier
is
used
rather
than
the
actual
value.
Maintenance
programmers
need
only
change
the
value
once.
VERSION
CONTROL
AND
REGULAR
BACKUP
During
coding
all
programmer
should
regularly
save
his
or
her
work.
This
is
to
prevent
loss
of
source
code
should
the
power
go
out,
however
it
also
allows
different
versions
of
the
program
or
more
often
the
current
module
or
even
subroutine
to
be
stored.
Often
when
coding,
programmers
arrive
at
a
solution
but
then
wish
to
test
various
modifications.
By
implementing
a
system
of
version
control
it
is
possible
to
effectively
maintain
different
versions
of
particular
modules.
If
a
modification
does
not
improve
the
solution
then
the
programmer
can
revert
to
an
earlier
version.
RECOGNITION
OF
RELEVANT
SOCIAL
AND
ETHICAL
ISSUES
When using code written by others it is important to respect their intellectual
property rights including but not limited to their legal rights
Thorough testing to ensure software performs correctly
Documentation for future maintainers of the software. Many successful applications
remain in use for decades. It is important that the source code can continue to be
understood
TYPES OF ERROR
SYNTAX ERRORS
Syntax
errors
are
any
errors
that
prevent
the
translator
converting
the
high-level
code
into
object
code.
A
syntax
error
is
an
error
in
the
source
code
of
a
program.
Since
computer
programs
must
follow
strict
syntax
to
compile
correctly,
any
aspects
of
the
code
that
do
not
conform
to
the
syntax
of
the
programming
language
will
produce
a
syntax
error.
LOGIC
ERRORS
A
logic
error
(or
logical
error)
is
a
mistake
in
a
program's
source
code
that
results
in
incorrect
or
unexpected
behaviour.
E.g.
Average=
Integer1
+
integer2
/
2
would
result
in
integer1
being
added
to
interger2
divided
by
2.
The
correct
logic
will
be
produced
using
Average=
(Integer1
+
integer2)
/
2. Logic
errors
are
the
most
difficult
errors
to
detect
as
they
are
syntactically
correct
and
do
not
cause
a
system
crash
but
instead
produce
incorrect
outputs.
It
is
essential
that
a
programmer
check
all
of
their
design
algorithms
to
avoid
these
errors
before
coding.
The
programmer
also
must
make
sure
they
are
coding
the
right
logic,
as
simple
logical
mistakes
can
occur.
RUNTIME
ERRORS
Runtime
errors
occur
while
the
program
is
running,
and
will
lead
to
a
crash.
Sometimes
they
are
caused
by
wrong
syntax,
other
times
they
are
caused
by
the
inability
of
the
computer
to
perform
the
intended
task.
Adam Florence SDD HSC Notes
54
Most
high-level
language
source
code
editors
in
integrated
development
environments
(IDE)
will
pause
the
execution
of
the
program
and
set
it
into
a
break
mode.
The
editors
will
indicate
the
line
in
which
the
error
occurred.
Runtime
errors
could
by
caused
by:
division
by
zero,
arithmetic
overflow
(when
a
value
is
assigned
to
a
variable
that
is
outside
the
range
allowed
for
that
data
type),
accessing
inappropriate
memory
locations.
METHODS
OF
ERROR
DETECTION
AND
CORRECTION
DEBUGGING
OUTPUT
STATEMENTS
Strategic
placement
of
temporary
output
statements
can
help
to
isolate
the
source
of
errors.
By
placing
output
statements
within
called
subroutines,
the
programmer
can
determine
which
subroutines
have
been
called.
This
assists
in
the
detection
of
the
source
of
an
error.
Often
a
debugging
output
statement
will
be
progressively
moved
as
the
debugging
process
continues.
In
this
way,
the
flow
of
execution
through
the
code
can
be
precisely
monitored.
Eventually
the
source
of
the
error
is
detected.
DESK
CHECKING
Desk
checking
is
the
process
of
working
through
an
algorithm
or
piece
of
source
code
by
hand.
A
table
with
a
column
for
each
variable
is
used.
As
the
algorithm
or
code
is
worked
through
by
hand,
writing
the
new
value
in
the
next
row
shows
changes
to
variables.
A
desk
check
is
particularly
useful
when
the
working
of
a
piece
of
source
code
are
not
fully
understood.
The
process
helps
to
make
the
logic
clear.
DRIVERS
A
driver
provides
an
interface
between
two
components.
A
driver
controls
the
operation
of
some
device.
For
example
a
hardware
driver
is
a
program
that
provides
the
link
between
the
operating
system
and
a
specific
hardware
device.
Another
example
is
a
printer
driver
used
to
control
the
operation
of
a
printer.
In
terms
of
software
development,
a
driver
is
a
subroutine
written
to
test
the
operation
of
one
or
more
other
subroutines.
Commonly,
drivers
set
the
value
of
any
required
variables,
call
the
subroutine
to
be
tested
and
output
the
results
of
the
subroutine
call.
Drivers
are
required
when
software
projects
are
coded
using
a
bottom-up
design
methodology.
Lower-level
subroutines
are
developed
before
higher-level
subroutines.
Because
of
this,
it
is
necessary
to
write
a
driver
to
test
the
operation
of
each
subroutine
as
it
is
being
coded.
FLAGS
Adam Florence SDD HSC Notes
55
A
flag
is
used
to
indicate
that
a
certain
condition
has
been
met.
Usually
a
flag
is
set
to
either
true
or
false,
Booleans.
Flags
are
sued
to
signify
the
occurrence
of
a
certain
event.
Flags
are
used
to
check
if
certain
sections
of
code
have
been
executed
or
certain
conditions
have
been
met.
For
example,
a
particular
flag
may
be
set
to
true
when
a
subroutine
is
called.
By
seeing
this
value,
the
programmer
can
determine
the
flow
of
control
through
the
program.
PEER
CHECKING
Often
errors
will
occur
that
seem
to
be
impossible
to
correct
for
the
original
programmer.
Colleagues
on
the
development
team
are
often
able
to
see
the
problem
from
a
fresh
point
of
view.
Many
software
companies
require
that
each
subroutine
is
peer
checked
as
pat
of
their
quality
assurance
strategy.
STRUCTURED
WALKTHROUGH
Structured
walkthroughs,
as
the
name
suggests,
are
more
formal
than
peer
checks.
The
developer
or
team
of
developers
present
their
work
to
a
group
of
interested
parties.
This
group
may
include
representatives
from
management,
marketing
and
potential
users.
The
developers
walk
the
group
through
each
aspect
of
the
program.
The
aim
is
to
receive
feedback
on
the
product
as
it
stand,
comments
are
written
down
for
future
consideration.
Structured
walkthroughs
are
normally
formal
meetings.
They
can
be
used
to
evaluate
the
design
at
different
levels.
Their
aim
is
to
explain
in
a
structured
manner
the
operation
of
some
part
of
the
design
and
development
process
and
to
obtain
feedback.
STUBS
A
stub
is
a
small
subroutine
used
in
place
of
a
yet
to
be
coded
subroutine.
The
use
of
stubs
allows
higher-level
subroutines
to
be
tested.
Stubs
do
not
perform
any
real
processing,
rather
they
aim
to
stimulate
the
processing
that
will
occur
in
the
final
subroutine
they
replace.
Stubs
are
used
to
set
the
value
of
any
variables
affecting
their
calling
routines
and
then
end.
Sometimes
a
stub
may
include
an
output
statement
to
inform
the
programmer
that
the
call
to
the
stub
has
been
successful.
The
creation
of
stubs
is
required
when
software
projects
are
coded
using
a
top-down
methodology.
Because
higher-level
subroutines
are
created
before
lower-level
subroutines,
it
is
necessary
to
create
dummy
subroutines.
This
enables
testing
of
the
higher-level
subroutines
whilst
they
are
being
coded.
USE
OF
EXPECTED
OUTPUT
When
initial
test
data
items
are
created
the
expected
output
from
these
inputs
should
be
calculated
by
hand.
Once
the
subroutine
has
been
coded,
the
test
data
is
entered
and
the
output
from
the
subroutine
is
compared
to
the
expected
outputs.
If
the
actual
and
expected
outputs
match
then
this
provides
a
good
indication
that
the
subroutine
works.
If
they
dont
then
clearly
a
logic
error
has
occurred.
Further
techniques
must
be
employed
to
determine
the
source
of
the
error.
USE
OF
SOFTWARE
DEBUGGING
TOOLS
BREAKPOINTS
Used
to
temporarily
halt
the
execution
of
the
code.
Once
execution
has
stopped,
it
is
possible
to
examine
the
current
value
of
each
variable.
By
adding
breakpoints
at
strategic
place
within
the
code,
it
is
possible
to
locate
the
source
of
the
error.
PROGRAM
TRACES
Adam Florence SDD HSC Notes
56
Tracing,
in
terms
of
error
detection,
refers
to
tracking
some
aspect
of
the
software.
A
program
trace
enables
the
order
of
execution
of
statements
to
be
tracked
or
the
changing
contents
of
variables
to
be
tracked.
Both
these
types
of
trace
involve
analysing
and
following
the
flow
of
execution.
RESETTING
VARIABLE
CONTENTS
Altering
the
value
of
variables
during
the
execution
of
code
can
be
useful
in
determining
the
nature
of
an
error.
The
ability
to
alter
a
variables
contents
can
also
allow
the
programmer
to
determine
which
values
are
causing
errors
without
the
need
for
the
variable
to
actually
attain
that
value
as
a
consequence
of
execution.
SINGLE
LINE
STEPPING
Single
line
stepping
is
the
process
of
halting
the
execution
after
each
statement
is
executed.
Each
statement
is
highlighted
as
it
is
executed.
A
simple
keystroke
allows
execution
to
continue
to
the
next
statement.
WATCH
EXPRESSIONS
A
watch
expression
is
an
expression
whose
value
is
updated
in
the
watch
window
as
execution
continues
usually
watch
expressions
are
variable
names.
By
combining
single
line
stepping
and
watch
expressions,
an
automated
desk
checking
system
can
be
created.
DOCUMENTATION OF A SOFTWARE SOLUTION
USER DOCUMENTATION
USER MANUAL
Quality user manuals aim to provide concise and accurate information in regard to the
operation and purpose of software. Topics in user manuals describe what tasks the
software can complete, why these tasks are required and how these tasks are completed
using the software. The information needs to be presented using a format that is appealing,
accessible and consistent. Often much of the information traditionally contained in a user
manual will be included in help files that are accessible directly from within the application.
REFERENCE MANUAL
Reference manuals are designed to be an efficient source of information. In terms of
software, a reference manual should succinctly describe each command within the
application. Reference manuals are not designed to be read from start to finish rather they
will be read in random order as needs arise.
Each command within the application should be listed in alphabetical order, this assists the
user in locating required information without the need to refer to the contents or index
pages. Normally each command is listed together with a brief description and succinct
example to illustrate its usage.
INSTALLATION GUIDE
Installation guides provide the user with sufficient information to successfully install the
software product on their machines. Hardware and software requirements will be included
together with step-by-step instructions to guide the user through the set-up process. Often
notes are included to help resolve common installation problems.
TUTORIAL
Tutorials provide instruction in the use of software products using example scenarios. The
user is lead step-by-step through the processes included in the product. The user performs
Adam Florence SDD HSC Notes
57
the
tasks
under
the
direction
of
the
tutorial.
Tutorials
are
designed
so
users
can
experience
real
world
use
of
the
application
before
using
their
own
data.
ONLINE
HELP
Each
of
the
above
types
of
user
documentation
can
be
in
either
printed
or
electronic
online
form.
It
is
now
common
for
most
user
documentation
to
be
provided
online
rather
than
as
printed
manuals.
Online
documentation
can
be
provided
as
Adobe
PDF
files
which
are
often
similar
in
structure
to
more
traditional
printed
manuals.
Hypertext
help
documents
allow
users
to
efficiently
search
for
specific
items
or
in
many
cases
they
allow
context
sensitive
help
to
be
provided
from
within
the
application.
When
the
user
selects
help
within
the
application
they
are
directed
to
the
most
relevant
help
topic
automatically.
TECHNICAL
DOCUMENTATION
LOG
BOOK
A
logbook
records
the
systematic
series
of
actions
that
have
occurred
during
the
development
of
a
project.
Logbooks
or
process
diaries
are
often
utilised
during
the
design
and
development
of
products
in
many
industries.
Maintaining
a
logbook
is
a
method
of
chronologically
recording
the
processes
undertaken
to
develop
a
final
product.
Individual
members
of
the
development
team
can
maintain
their
own
logbooks
or
a
central
logbook
can
be
maintained
for
each
product
under
development.
SYSTEMS
DOCUMENTATION
There
are
numerous
different
methods
for
modelling
different
aspects
of
the
software
engineering
process.
System
modelling
tools
include:
context
diagram,
DFDs,
structure
charts
etc.
ALGORITHMS
An
algorithm
is
a
method
of
solution
for
a
problem.
Algorithms
describe
the
steps
taken
to
transform
inputs
into
the
required
outputs.
Each
algorithm
will
have
a
distinct
start
and
end,
and
will
be
composed
of
the
three
control
structures:
sequence,
decision,
and
repetition.
Algorithms
are
described
using
an
algorithm
description
language:
pseudocode
or
flowcharts.
SOURCE
CODE
The
source
code
itself
is
probably
the
most
important
form
of
technical
documentation.
It
is
virtually
impossible
to
isolate
logic
errors
in
an
application
without
access
to
the
original
source
code.
For
source
code
to
be
a
valuable
technical
resource
for
future
maintainers,
it
must
be
intelligently
documented.
Internal
Documentation
Comments
Intrinsic
Documentation
Meaningful
Identigiers
Indenting Code
Other
Formatting
Features
Documentation
within
the
source
code
is
often
called
internal
documentation.
Internal
documentation
can
take
two
forms,
comments
and
intrinsic
documentation.
Let
us
examine
each
of
these
in
turn.
Comments
provide
information
for
future
programmers.
The
translator
ignores
comments,
or
remark
statements,
within
the
code.
Each
procedure,
function
and
logical
process
within
Adam Florence SDD HSC Notes
58
the
code
should
be
preceded
by
a
comment.
Comments
should
explain
what
a
section
of
code
does
rather
than
how
it
does
it.
Intrinsic
means
belonging
by
its
very
nature.
Intrinsic
documentation
is
therefore
documentation
that
is
part
of
the
code
by
its
very
nature.
In
other
words,
the
code
is
self-
documenting.
There
are
two
main
types
of
intrinsic
documentation:
meaningful
identifiers
and
indentation.
An
identifier
is
the
name
given
to
a
variable,
procedure
or
function.
They
should
describe
the
purpose
of
the
element
it
represents.
Indenting
is
the
process
of
setting
lines
of
code
back
from
the
left
margin.
Indenting
sections
of
code
within
control
structures
improves
the
readability
of
code.
Many
other
formatting
features
are
commonly
used
to
improve
the
intrinsic
readability
of
code.
Leaving
blank
lines
between
comments
and
the
code
they
describe.
Colour
can
be
used
to
visually
differentiate
between
comments,
reserved
words,
operators
and
operands.
Any
factors
that
increase
the
readability
of
the
source
code,
and
are
part
of
the
code,
are
classified
as
intrinsic
documentation.
HARDWARE ENVIRONMENT TO ENABLE IMPLEMENTATION OF THE SOFTWARE
All software solutions are designed with particular hardware requirements in mind. The
installation guide will include specifications in regard to minimum requirements, possible
additional hardware and appropriate drivers. Large custom systems are usually designed for
a specific hardware configuration. Solutions designed for a broad market need to operate on
a variety of hardware configurations. The hardware requirements need to be specified and
tested before software solutions are released.
MINIMUM HARDWARE CONFIGURATION
The minimum hardware requirements will vary for different software solutions. The
following checklist lists hardware items that need to be considered by the software
developer for all solutions:
Processor type and speed
RAM size and type
Secondary storage size and access speed
Input devices
Output devices
Network hardware
The
minimum
configuration
should
allow
the
software
to
operate
successfully
with
acceptable
performance
and
response
times.
POSSIBLE
ADDITIONAL
HARDWARE
Additional
hardware
items
are
those
items
supported
by
the
software
product
but
not
essential
for
its
operation.
Extra
RAM
may
allow
the
product
to
operate
with
larger
files.
Sound
cards
may
allow
for
optional
audio
feedback
for
the
sight
impaired.
The
addition
of
a
network
or
internet
connection
may
allow
for
foreign
exchange
rates
to
be
updated
electronically
in
financial
packages.
APPROPRIATE
DRIVERS
OR
EXTENSIONS
Hardware
devices
require
software
drivers
to
allow
them
to
communicate
with
the
system.
These
drivers
are
also
known
as
interfaces,
as
they
convert
signals
from
one
device
into
those
that
can
be
understood
by
another.
Before
a
hardware
device
can
be
used
by
a
Adam Florence SDD HSC Notes
59
software
solution,
its
driver
must
be
correctly
installed
and
configured.
Most
peripheral
devices
come
packaged
with
drivers
for
most
popular
OSs
or
are
able
to
use
drivers
included
with
the
OS.
The
driver
is
installed
as
part
of
the
installation
of
the
hardware
device.
Custom
built
hardware
may
require
a
purpose
built
driver
to
be
created.
This
driver
would
need
to
be
installed
as
part
of
the
installation
of
the
software
solution.
In
this
case,
the
driver
is
an
extension
to
the
software
package.
For
example,
a
product
designed
to
monitor
the
climate
within
a
green
house
includes
custom
drivers
for
the
temperature
and
humidity
sensors.
These
sensors
are
part
of
the
minimum
hardware
requirements
for
this
product.
The
drivers
or
extensions
are
installed
as
the
main
application
is
installed.
9.2.4 TESTING AND EVALUATING OF SOFTWARE SOLUTIONS
TESTING THE SOFTWARE SOLUTION
COMPARISON OF THE SOLUTION WITH THE DESIGN SPECIFICATIONS
The original specifications and requirements, which may have been modified during the
development of the product, must be tested for compliance. The aim of the project is to
implement the full set of design specifications. Because the requirements are written in such
a way that they can be readily tested, a pass or fail can be allocated to each requirement. A
checklist of all requirements is used. Each requirement is tested in turn. If faults are
encountered then that aspect of the product is altered until the requirement is met.
During the testing and evolution stage we aim to identify any errors, omissions and other
problems within the product. Some problems may not be errors rather they maybe usability
or hardware compatibility issues. Each problem identified will result in further development
to correct the problem.
There are essentially two techniques used to test software solutions: white box testing
(technique whereby explicit knowledge of the internal workings of the item being tested is
used) and black box testing (the inputs and expected outputs are known, the processes
occurring are unknown). Both techniques are required to identify and correct the majority of
errors. Black box testing does not attempt to identify the source of the problem, but rather
to identify that a problem exists. Once the problem has been identified, it may be necessary
to move to white box testing to find and correct the problem. At this stage, we are primarily
concerned with black box testing techniques.
GENERATING RELEVANT TEST DATA FOR SOFTWARE SOLUTIONS
There are often way too many variables to test. They would take too much time and money
to test all of them. So a range of techniques are used to cover a wide range of conditions.
Black Box or functional testing checks the inputs of each module against the expected and
the actual outputs. The user is more concerned with black box testing as it involves what
they see, that is, the input and outputs. Identifies logical and run-time overflow errors.
Types of Black Box testing:
Range checking: The upper and lower values are checked
Critical value checking: the conditional values are checked
Equivalence partitioning: A range of different data types are checked
White-box
or
structural
testing:
checks
the
procedures
or
processes
within
each
module
to
determine
their
correctness.
It
is
what
the
programmer
is
more
concerned
with
as
it
identifies
bugs
in
the
coded
solution.
Types
of
white-box
testing:
Adam Florence SDD HSC Notes
60
Statement
coverage
testing:
test
data
is
chosen
to
test
each
statement
in
a
module
Decision
condition
testing:
Test
data
is
selected
to
test
each
decision
within
a
module
COMPARISON
OF
ACTUAL
WITH
EXPECTED
RESULTS
Test
data
should
be
entered
into
the
finished
product
to
ensure
the
actual
outputs
match
the
expected
outputs.
Because
the
correct
outputs
are
already
known,
this
testing
process
ensure
the
final
product
is
able
to
perform
its
processing
correctly.
LEVELS
OF
TESTING
Testing
is
done
progressively;
it
starts
at
the
lowest
level,
i.e.
unit
testing,
than
works
towards
program
testing
and
finally
system
testing
where
it
is
testing
in
different
environments.
Errors
can
be
removed
from
the
bottom
up.
MODULE
Tests
each
module
separately
and
makes
sure
that
each
module
is
performing
their
task
successfully.
A
driver
program
may
be
needed
to
provide
inputs
and
outputs
to
and
from
a
module,
as
the mainline
may
not
be
available
at
this
time.
Within
complex
programs,
module
testing
will
involve
integrating
related
modules
and
testing
them as
a
subsystem.
Black
and
white
box
testing
is
used.
PROGRAM
Ensures
that
the
modules
work
together
and
that
the
mainline
of
the
program
performs
correctly.
Concentrates
on
the
interfaces
and
the
relationship
of
each
module
to
the
mainline.
Uses
white
and
black
box
testing
to
ensure
the
program
performs
the
overall
task(s)
set
in
the design
specifications.
Can
be
done
in
two
different
ways:
Bottom-up
testing:
test
and
corrects
the
lowest
level
modules
first
and
works
up
to
the
higher-level
modules.
Relies
extensively
on
driver
programs
to
test
modules.
Easier
to
detect
problems
at
an
earlier
stage.
The
main
program
is
tested
last
once
all
modules
are
in
place.
Top-down
testing:
starts
with
testing
the
main
program
first
and
uses
stubs
for
some
incomplete
modules
as
it
links
each
module
to
the
main
line.
Any
problems
are
most
likely
to
be
caused
by
the
most
recent
addition,
therefore
problems
can
be
easily
located
if
top-down
testing
is
constantly
used.
Matters
on
preference
and
commonsense.
E.g.
a
library
of
routines
may
already
be
checked
and
free
from
errors,
so
it
would
be
more
reasonable
to
use
a
top-down
approach.
A
bottom-up
approach
would
be
more
useful
if
a
program
and
all
of
its
modules
are
built
from
scratch.
SYSTEM
Uses
black
box
testing
to
check
that
the
program
can
run
outside
the
integrated
development
environment
in
a
range
of
other
environments. E.g.
a
program
may
run
excellently
on
one
set
of
hardware
and
software,
yet
if
you
try
it
on
a
different
set
of
hardware
and
software
configurations,
problems
that
were
never
present
on
the
development
machine
are
now
an
issue
on
several
machines
and
must
be
fixed.
Testers
outside
of
the
development
team
often
do
system
testing.
For
custom
software,
the
program
is
tested
in
the
environment
in
which
it
will
be
used.
Acceptance
testing
(for
custom
software):
using
potential
users
of
a
program
to
test
custom software
that
is
only
designed
to
run
for
one
particular
set
of
hardware
and
software
specifications.
This
allows
a
program
to
optimise
for
one
particular
system.
Adam Florence SDD HSC Notes
61
E.g.
PlayStation
3
console
is
only
one
system
and
exclusive
game
developers
can
run
acceptance
testing
with
users
to
optimise
their
game
for
the
PS3
system
only.
Alpha
testing
(more
general/commercial
software):
is
the
first
phase
of
testing
done
under
controlled
conditions
with
selected
participants.
Once
all
initial
alpha
bugs
found
have
been
fixed
beta
testing
takes
place.
Beta
testing
(more
general/commercial
software):
is
the
second
phase
of
testing
and
involves
volunteers
to
test
a
program
on
a
wide
range
of
specified
hardware
and
software
systems.
E.g.
Windows
7
Beta
could
be
downloaded
freely
and
tested
by
a
wide
range
of
users
systems.
These
provide
an
enormous
amount
of
feedback
very
quickly
to
the
developers
and
final
bugs
of
the
beta
stage
can
be
fixed
up
before
the
release
candidate
is
released.
USE
OF
LIVE
TEST
DATA
When
a
system
is
finally
installed
and
implemented
within
the
total
system
it
is
said
to
be
live.
Once
a
product
goes
live
it
needs
to
undergo
a
series
of
tests
to
ensure
its
robustness
under
real
conditions.
This
testing
occurs
using
live
test
data.
Live
test
data
is
produced
to
simulate
extreme
conditions
that
could
conceivably
occur.
The
use
of
live
test
data
aims
to
ensure
the
software
product
will
achieve
its
requirements
under
these
extreme
conditions.
Different
sets
of
live
test
data
are
used
to
test
particular
scenarios.
CASE
tools
are
available
to
assist
in
the
task
of
producing
live
test
data
sets
and
also
to
automate
the
testing
process.
Later
in
this
chapter,
we
examine
CASE
tools
used
for
this
purpose.
For
most
products
live
test
data
should
be
created
to
test
each
of
the
following
conditions
LARGE
FILE
SIZES
Many
commercial
applications
obtain
input
from
large
databases.
During
the
development
of
software
products,
relatively
small
data
sets
are
used.
At
the
alpha
and
beta
testing
stages
large
files
should
be
used
to
test
the
systems
performance.
The
use
of
large
files
will
highlight
problems
associated
with
data
access.
Often
systems
that
perform
at
acceptable
speeds
with
small
data
files
become
unacceptably
slow
when
large
files
are
accessed.
This
is
particularly
the
case
when
data
is
accessed
via
networks.
Large
data
files
highlight
aspects
of
the
code
that
are
inefficient
or
require
extensive
processing.
Many
large
systems
will
postpone
intensive
processing
activities
until
times
when
system
resources
are
available.
For
example,
updating
of
bank
account
transactions
takes
place
during
the
night
when
processing
resources
are
available.
MIX
OF
TRANSACTION
TYPES
Testing
needs
to
include
random
mixes
of
transaction
types.
Module
and
program
testing
usually
involve
testing
specific
transactions
or
processes
one
at
a
time.
During
system
testing
we
need
to
test
that
transactions
occurring
in
random
order
to
no
create
problems.
Often
the
results
of
one
process
will
influence
a
number
of
other
processes.
If
a
transaction
is
currently
being
completed
on
specific
data
and
that
data
is
altered
by
another
transaction
then
problems
can
occur.
When
a
number
of
applications
are
used
to
access
the
same
database
then
conflicts
are
inevitable.
Software
must
include
mechanisms
to
deal
with
such
eventualities.
RESPONSE
TIMES
The
response
time
is
the
time
taken
for
a
process
to
complete.
The
process
could
be
user
activated
or
it
could
be
activated
internally
by
the
application.
Response
times
are
Adam Florence SDD HSC Notes
62
dependent
on
all
the
system
components,
together
with
their
interaction
with
each
other
and
other
processes
that
may
be
occurring
concurrently.
Any
processes
that
are
likely
to
take
more
than
one
second
should
provide
feedback
to
the
user.
Progress
bars
are
a
common
way
of
providing
this
feedback.
Data
entry
forms
that
need
to
validate
data
before
continuing
should
be
able
to
do
so
in
less
than
one
second,
0.1
seconds
is
preferable.
Response
times
should
be
tested
on
minimum
hardware
using
typical
data
of
different
types.
Any
applications
that
affect
and/or
interface
with
the
new
product
should
be
operating
under
normal
of
heavy
loads
when
the
testing
takes
place.
VOLUME
DATA
(LOAD
TESTING)
Large
amounts
of
data
should
be
entered
into
the
new
system
to
test
the
application
under
extreme
load
conditions.
Multi-user
products
should
be
tested
with
large
numbers
of
users
entering
and
processing
data
simultaneously.
Large
systems
that
require
extensive
data
input
require
special
consideration.
Alpha
testing
by
the
software
developer
must
try
to
simulate
the
number
of
users
who
will
simultaneously
use
the
product.
This
can
by
done
using
a
laboratory
of
computers
and
users
in
conjunction
with
CASE
tools.
In
many
cases,
it
is
difficult
to
simulate
real
volumes
of
data
in
a
beta
testing
environment
without
actually
implementing
the
system.
CASE
tools
are
available
that
enable
automatic
completion
of
data
entry
forms.
Many
of
these
tools
allow
the
creation
of
virtual
users.
This
allows
one
machine
to
simulate
the
activities
of
hundreds
or
even
thousands
of
simultaneous
users
entering
data.
INTERFACES
BETWEEN
MODULES
AND
PROGRAMS
An
interface
provides
a
communication
link
between
system
components.
In
terms
of
modules
within
a
program,
the
interface
is
usually
provided
through
the
use
of
parameters
that
are
used
to
pass
data
to
and
from
modules.
The
screens
of
an
application
provide
and
interface
between
the
users
and
the
program.
Hardware
drivers
are
programs
that
provide
an
interface
between
applications
and
hardware
devices.
Programs
that
interact
with
other
programs
require
an
interface
to
complete
their
tasks.
All
these
interfaces
require
testing.
REPORTING ON THE TESTING PROCESS
DOCUMENTATION OF THE TEST DATA AND OUTPUTS PRODUCED
When testing in a commercial environment it is important that the process is fully
documented. This allows the project leader to be fully informed of relevant issues and how
they were handled. It also ensures that the final system has been through a rigorous testing
process, resulting in a quality product. It is one of the steps in quality assurance.
CASE tools are used to automate and assist developers with documentation. There are two
types:
General
application
CASE
tools:
suitable
for
creating
written
reports
and
for
basic
analysis
of
some
results.
E.g.
word
processors
and
spreadsheets.
Specialized
CASE
tools:
provide
structure
assistance,
sometimes-automated
processes
and
the
development
of
test
data.
Examples of specialized CASE tools:
Oracle: program used to generate what the expected results will be
Test data generator: develops a variety of large amounts of test data.
Data dictionary creators: allows data to be tested against the data criteria.
Adam Florence SDD HSC Notes
63
File
comparisons
ensures
input
files
follow
set
rules
and
output
files
are
correct.
Test
management:
tracks
test
data
and
results.
Conducts
tests
of
multiple
modules.
Volume
tester:
used
to
test
a
program
under
network
conditions
with
high
amounts
of
users.
Functional
tester:
Provides
user
interaction
with
a
program
to
test
all
possible
pathways
by
inputting
test
data
to
cover
all
pathways.
Dynamic
analyser:
allows
statements
to
be
counted
every
time
they
are
executed.
Simulator:
creates
a
real
time
environment
in
which
the
program
can
be
tested.
An
example
of
a
test
report
for
a
payroll
system
currently
being
developed
is
shown
below.
Note
the
inclusion
of
a
narrative
discussion
of
problems
encountered
during
testing,
a
table
of
expected
outcomes
and
a
table
of
what
occurred
during
testing.
Note:
This
is
just
one
possible
representation.
There
are
many
other
valid
ways
of
documenting
the
testing
process.
Adam Florence SDD HSC Notes
64
COMMUNICATION
WITH
THOSE
FOR
WHOM
THE
SOLUTION
HAS
BEEN
DEVELOPED
Communicating
with
clients
or
users
must
be
done
in
an
honest,
direct
and
non-technical
way. This
will
ensure
the
program
meets
the
specifications,
if
not,
the
program
can
be
easily
adjusted
to
meet
them.
TEST
RESULTS
Test
results
should
document
both
the
positive
and
negative
experiences
of
a
program.
They
should
include:
Problems
should
be
identified
such
as
bugs,
length
response
times,
inability
to
test
a
module due
to
lack
of
data
input.
Limitations
of
the
program:
scope
or
size
of
the
data
type
handling
capacity.
Data
input restrictions
and
processing
limits
are
placed
here.
Assets:
user
interface,
results
from
live
data
and
results
that
show
user
needs
being
met
are documented
here.
Recommendations
should
be
made
such
as
that
certain
bugs
will
be
fixed
in
feature
development,
modules
will
be
rewritten
or
a
program
is
open
to
new
features.
COMPARISON
WITH
THE
ORIGINAL
DESIGN
SPECIFICATION
Summary
of
the
program
and
its
tasks,
which
compare
to
the
design
specifications,
are
communicated
to
the
client
base.
Any
specifications
that
have
not
been
met
should
be
alerted
to
the
client
and
a
reason
why
it wasnt
met.
If
possible
these
problems
should
be
fixed.
EVALUATING THE SOFTWARE SOLUTION
VERIFYING THE REQUIREMENT HAVE BEEN MET APPROPRIATELY
The major aim of testing is to detect and correct errors before the system is installed for use.
At the system level we are largely concerned with assessing the extent to which all the
requirements and design specifications have been met. This assessment has the added
bonus of providing critical information with which to evaluate both the new system and also
to evaluate the design and development process including the quality assurance procedures.
Adam Florence SDD HSC Notes
65
The
original
design
specifications
include
requirements
for
the
particular
application
together
with
specifications
in
regard
to
documentation
required,
screen
design
and
code
design.
In
essence,
these
specifications
describe
what
the
software
should
do
together
with
how
it
should
be
done.
Evaluation
of
the
design
specifications
will
therefore
ensure
the
product
realises
its
requirements
and
that
those
involved
in
the
design
process
have
maintained
standards
in
regard
to
how
the
requirements
have
been
achieved.
POST IMPLEMENTATION REVIEW
CLIENT EVALUATION AND SIGN-OFF PROCESS
A review of the system once operational is often undertaken prior to the client formally
accepting the software as complete. For smaller projects this evaluation is often in the form
of discussion between the client and the installers. Commonly the discussion will include
demonstrations to confirm and describe how the requirements have been met. For large
system professional independent assessors perform thorough and rigorous acceptance tests
followed by a formal review.
Acceptance tests are designed to confirm the requirements have been met so the system
can be signed off as complete. The client and the developers usually agree to use the results
of the acceptance tests as the basis for determining completion of the new system. If the
tests are successful then the client makes their final payment and the development teams
job is complete.
9.2.5 MAINTAING SOFTWARE SOLUTIONS
MODIFYING CODE TO MEET CHANGED REQUIREMENTS
IDENTIFYING REASONS FOR CHANGE IN SOURCE CODE
The possible reasons for changing source code are many and varied. Reasons for change
common to all applications include:
Bud
fixes
New
hardware
New
software
purchases
Major
upgrades
of
OSs
will
have
a
flow-on
effect
to
other
applications.
Upgrading
of
applications
to
take
advantage
of
features
available
in
new
OSs
required.
A
software
company
whose
products
have
a
large
customer
base
may
receive
many
thousands
of
requests
for
modification
of
their
products.
The
company
must
then
prioritise
these
requests
and
make
decisions
on
which
modifications
will
be
included
and
which
will
not.
Often
registered
users
are
surveyed
to
obtain
their
views
on
possible
modifications.
Support
departments
provide
a
valuable
source
of
data.
The
number
of
support
issues
about
specific
function
highlights
useability
problems.
This
information
can
be
used
as
the
basis
for
selecting
appropriate
modifications
for
inclusion
in
an
upgrade.
Customised
software
written
for
a
specific
client
will
require
continual
maintenance
as
requirements
change.
The
focus
of
companies
change,
small
companies
will
grow
ad
their
products
will
change.
As
customised
software
is
an
extensive
purchase,
maintaining
the
product
is
normally
preferable
to
changing
products,
or
developing
a
new
product
from
the
ground
up.
Because
custom
software
is
written
to
solve
a
particular
problem,
minor
changes
to
the
requirements
often
necessitate
alterations
and
additions
to
the
source
code.
Adam Florence SDD HSC Notes
66
Software
based
on
COTS
products
is
particularly
susceptible
to
upgrades
in
the
base
COTS
product.
Macro
and
script
commands
may
change,
resulting
in
unexpected
results.
Often
applications
will
need
to
be
recompiled
using
the
new
version
of
the
COTS
product.
The
internet
has
automated
the
upgrading
of
many
commonly
used
applications.
Products
using
the
resources
of
these
applications
may
require
similar
upgrading
to
continue
to
operate
as
intended.
LOCATING
OF
SECTION
TO
BE
ALTERED
Once
a
decision
has
been
made
to
modify
a
particular
aspect
of
a
product,
the
location
of
the
section
to
be
altered
needs
to
be
determined.
Models
of
the
system
are
used
to
assist
in
this
process.
Structure
charts
and
DFDs
will
assist
in
the
location
of
the
modules
requiring
modification.
Once
a
module
has
been
identified,
the
programmer
can
analyse
the
original
algorithms
and
IPO
diagrams,
and
the
actual
source
code.
A
thorough
understanding
of
the
original
source
code
is
required
before
any
modifications
are
undertaken.
DETERMINING
CHANGES
TO
BE
MADE
After
the
section
of
code
to
be
modified
has
been
located,
we
need
to
determine
the
changes
to
be
made.
Depending
on
the
nature
of
the
modification,
changes
may
be
required
to
data
structures,
files,
and
the
user
interface,
as
well
as
to
the
source
code.
The
consequences
of
changes
made
to
one
module
must
be
considered.
If
a
record
data
structure
is
altered
then
what
effect
will
this
have
on
other
modules
that
access
this
data?
For
example,
if
a
field
within
a
record
that
once
contained
Boolean
data
is
change
to
hold
integers,
then
there
will
be
consequences
for
all
modules
that
access
these
records.
Analysis
of
the
original
documentation
should
alert
programmers
to
the
possible
consequences
of
changes.
IMPLEMENTING
AND
TESTING
SOLUTION
Once
the
changes
to
be
made
have
been
determined,
these
changes
must
be
implemented
within
the
existing
application.
In
many
cases,
changes
will
be
made
to
the
source
code
and
the
application
will
be
recompiled,
tested
and
distributed.
In
other
cases,
a
small
application
or
patch
may
be
written
to
implement
the
changes
on
end-users
systems.
Customs
systems,
written
using
COTS
products,
can
often
be
changed
directly
on
the
site
or
over
an
internet
link.
This
is
particularly
the
case
with
script
and
macro
modifications.
In
many
cases,
script
and
macros
are
not
compiled
until
runtime,
so
the
source
code
is
available
for
change
at
the
end-users
site.
The
implementation
of
modifications
can
have
a
ripple
effect
to
other
aspects
of
the
application.
These
problems
are
minimised
if
the
original
product
was
designed
using
a
structured
modular
approach.
When
each
procedure
or
function
has
been
designed
independently
then
the
effect
of
changes
will
be
easier
to
identify
and
correct.
Modules
that
are
used
in
a
number
of
places
throughout
the
application
should
be
modified
in
such
a
way
that
they
retain
their
original
processing,
including
input
and
output
parameters.
Changes
to
modules
that
alter
parameters
will
require
modifications
to
each
higher-level
calling
module.
Testing
of
modifications
should
be
performed
using
the
same
techniques
employed
for
the
development
of
new
products.
Often
CASE
tool
scripts
and
test
data
used
during
the
original
testing
can
be
reused.
The
tests
should
not
be
restricted
to
the
modified
code
segments,
but
applied
to
all
aspects
of
the
application
that
are
in
any
way
affected
by
the
change.
DOCUMENTING
CHANGE
SOURCE
CODE
DOCUMENTATION
Adam Florence SDD HSC Notes
67
Documentation
of
the
source
code
includes
comments
and
intrinsic
documentation.
The
major
function
of
source
code
documentation
is
to
ease
the
job
of
maintenance
programmers.
Often
documenting
code
at
the
time
of
writing
is
viewed
as
tedious,
however
at
maintenance
time
this
documentation
will
prove
invaluable.
As
source
code
is
written
the
programmer
obviously
understands
the
logic.
At
the
time
they
are
written,
many
statements
within
the
source
code
will
appear
trivial
however
the
code
will
not
be
so
obvious
when
viewed
by
other
programmers
at
a
later
date.
Comments
should
be
included
that
clearly
describe
what
each
code
segment
does.
The
code
should
be
self-
documenting
so
that
it
clearly
explains
how
the
code
segment
achieves
its
purpose.
Careful
documentation
of
any
changes
made
to
the
original
code
must
be
maintained.
Details
of
who
made
the
change,
and
when,
should
be
included
within
the
code.
Any
original
comments
that
are
no
longer
relevant
should
be
removed
or
modified.
It
is
vital
that
the
integrity
of
the
documentation
be
maintained
throughout
the
modification
of
the
product.
UPDATING
ASSOCIATED
HARDCOPY
DOCUMENTATION
AND
ONLINE
HELP
Printed
documentation
is
becoming
a
rare
occurrence
as
a
means
of
distributing
documentation.
In
most
cases
user
and
technical
documentation
is
stored
and
distributed
electronically.
Electronic
formats
allow
for
more
efficient
editing
and
distribution
of
all
types
of
documentation.
Most
software
products
now
contain
online
help
files.
Most
OSs
have
their
own
standard
format
for
online
help
files.
They
also
contain
an
application
to
access
these
files.
Most
high-level
languages
now
include
development
tools
to
assist
in
the
integration
of
online
help
within
products.
Maintenance
personal
must
consider
the
effect
on
the
integrity
of
online
help
of
modification
made
to
products.
Additions
and
modification
to
the
online
help
system
should
be
made
in
order
to
reflect
any
modification
made
to
the
application.
USE
OF
CASE
TOOLS
TO
MONITOR
CHANGES
AND
VERSIONS
Maintaining
accurate
records
of
the
maintenance
process
is
a
complex
and
time-consuming
task.
CASE
tools
are
available
to
automate
this
process.
The
systematic
control
of
changes
to
a
software
product
is
known
as
configuration
management.
Many
CASE
tools
specifically
designed
to
serve
the
process
of
configuration
management
are
available.
Some
of
the
functions
commonly
addressed
in
these
CASE
tools
include:
Change
management-
supports
the
life
cycle
of
each
change,
beginning
with
the
initial
change
request
to
the
inclusion
of
the
modification
into
the
final
product.
Each
step
of
the
software
development
process
for
each
modification
is
monitored.
For
example,
a
history
is
maintained
of
each
modification
made,
when
it
was
made,
and
by
whom
Parallel
development-
maintenance
of
products
by
large
teams
of
developers
requires
significant
coordination.
Parallel
development
CASE
tools
enable
multiple
users
to
work
on
the
same
project
without
fear
of
duplication
or
destroying
another
team
members
work.
Individual
files
are
checked
out
as
required
by
individual
team
members.
This
effectively
locks
the
file,
preventing
others
from
making
modifications.
When
the
modification
is
complete,
the
file
is
checked
in.
The
checking-in
process
releases
the
file
and
retains
a
record
of
the
changes
made.
Distributed
parallel
development
tools
create
scripts
of
changes
made
to
each
file;
these
scripts
are
distributed
electronically
to
other
teams
members.
This
ensures
developers
work
with
the
most
up-to-date
code
available
Version
control-
CASE
tools
manage
multiple
versions
of
software
components
or
modules.
The
system
tracks
which
version
of
each
component
of
module
should
be
used
when
the
application
is
finally
reassembled.
A
record
is
maintained
of
prior
Adam Florence SDD HSC Notes
68
versions of components, allowing the reconstruction of previous versions of the
application
9.4
OPTIONS
9.4.1
OPTION
1
PROGRAMMING
PARADIGMS
DEVELOPMENT
OF
DIFFERENT
PARADIGMS
A
paradigm
can
be
defined
as
a
model
or
pattern.
In
relation
to
computer
programming
it
relates
to
the
way
a
solution
to
a
problem
is
structured
not
how
it
is
coded.
Another
term
closely
related
to
paradigm
is
methodology,
which
relates
to
the
approach
used
when
writing
program
code.
Until
relatively
recently,
the
architecture
of
computer
hardware
had
driven
the
development
of
programming
languages.
Although
many
different
computer
architectures
are
currently
being
developed,
by
far
the
most
common
is
still
the
traditional
Von
Neumann
architecture
first
developed
to
calculate
trajectories
for
bombs
and
shells
during
WWII.
The
Von
Neumann
architecture
was
implemented
in
the
ENIAC
(electronic
numerical
integrator
and
computer).
Probably
every
computer
you
have
seen
or
used
is
based
on
the
Von
Neumann
concept.
Essentially,
this
architecture
separates
data
and
processing.
Data
is
sent
to
the
CPU
for
processing
and
the
result
is
sent
back
to
memory
for
storage.
The
CPU
is
a
sequential
device;
instructions
are
processed
one
at
a
time
in
a
predetermined
sequence.
The
Von
Neumann
computer
has
lead
to
the
development
of
procedural
or
imperative
languages.
Imperative
languages
use
sequencing,
decisions
and
repetition
as
their
main
problem
solving
methods.
Data
and
processing
are
separated
with
imperative
languages.
We
create
variables
for
data
storage
and
then
we
perform
processes
on
them.
Each
program
has
a
beginning
and
a
distinct
end.
This
is
not
the
only
way
of
doing
things.
LIMITATIONS
OF
THE
IMPERATIVE
PARADIGM
Although
new
imperative
programming
languages
and
user-friendly
GUI
interfaces
have
made
the
development
of
software
an
easier
task,
the
resulting
products
are
still
performing
the
same
tasks
using
essentially
the
same
techniques.
The
difference
is
they
are
just
doing
it
a
lot
faster.
Imperative
languages
require
the
developer
to
understand
all
details
of
the
problem
and
to
be
able
to
solve
the
problem
completely.
Many
types
of
problem
do
not
have
precise
solutions
and
developing
an
algorithm,
which
solves
such
problems,
is
not
feasible.
The
imperative
paradigm
on
which
languages
such
as
Pascal,
C,
Fortran
and
Basic
are
based,
restrict
the
developer
in
many
ways.
For
instance,
a
function
can
only
accept
data
as
its
inputs
and
it
can
only
return
data
as
its
output.
Individual
programs
are
designed
to
solve
a
particular
problem
and
they
must
be
modified
to
solve
related
problems.
The
human
brain
can
use
the
solution
techniques
used
on
past
problems
to
assist
in
the
resolution
of
new
seemingly
unrelated
problems.
As
human
beings
we
do
not
think
in
terms
of
data
and
processes,
our
brains
are
able
to
readily
connect
the
two.
The
human
brain
is
able
to
make
inferences
and
deduction
based
on
experience
and
intuition.
Surely
if
we
can
create
programming
languages
that
can
simulate
the
brain
more
accurately
then
productivity
gains
will
result.
DIFFICULTY
SOLVING
CERTAIN
TYPES
OF
PROBLEM
Adam Florence SDD HSC Notes
69
Computers
were
initially
designed
to
solve
mathematical
are
arithmetical
problems.
The
finance
and
motivation
for
the
development
and
production
of
early
computers
came
from
the
military.
This
was
soon
followed
by
statistical
analysis
of
census
data
and
then
by
large
business
applications.
These
problems
were
best
solved
using
mathematical
techniques.
Many
real
life
problems
do
not
have
definite
answers
or
they
have
a
variety
of
answers.
Other
problems
can
be
solved
using
strategies
that
cannot
be
stated
easily
in
strict
mathematical
terms.
For
example,
doctors
diagnose
diseases
in
patients
using
symptoms
and
a
certain
amount
of
intuition
gained
from
experience
with
other
patients.
Driving
a
car
involves
far
more
knowledge
than
knowing
how
to
operate
the
controls.
Good
drivers
are
able
to
become
an
integral
part
of
the
vehicle,
they
sense
potential
dangers
before
they
become
problems.
Communication
between
people
involves
multiple
signals.
Tone,
volume
and
inflexions
in
voice
have
different
subtle
meanings;
unable
to
be
solved
efficiently
using
imperative
languages.
A
different
set
of
rules
governs
the
solution
of
these
types
of
problem.
A
new
programming
paradigm
that
could
help
software
developers
work
towards
solutions
to
these
problems
would
be
invaluable.
THE
NEED
TO
SPECIFY
CODE
FOR
EVERY
INDIVIDUAL
PROCESS
The
imperative
paradigm
requires
that
every
part
of
the
problem
must
be
solved
in
complete
detail
before
the
final
software
will
operate.
For
example,
when
using
top-down
design
thorough
testing
cant
commence
until
the
final
lowest
level
subroutines
have
been
written.
Imagine
the
subroutine
required
to
sort
was
not
present
within
a
database
management
system,
the
whole
application
would
fail
even
though
this
sort
subroutine
is
a
very
minor
part
of
the
large
application.
Now
imagine
it
was
not
necessary
to
specify
details
of
every
single
process.
Instead
imagine
the
software
could
infer
a
suitable
method
of
solution
at
runtime.
If
this
were
the
case
then
software
will
be
able
to
react
to
the
changing
needs
of
users
without
the
need
for
modification.
This
is
a
significant
aim
of
the
logic
paradigm
and
is
why
the
logic
paradigm
is
used
to
develop
many
AI
applications.
DIFFICULTY
OF
CODING
FOR
VARIABILITY
Many
problems
solved
by
software
developers
are
similar
in
many
ways
or
involve
similar
solutions
strategies,
e.g.
searching
and
sorting.
There
are
countless
other
example
where
programming
tasks
are
repeated
as
part
of
the
solution
to
multiple
problems.
Well-
structured
imperative
programs
can
be
designed
so
that
modules
of
code
can
be
readily
reused.
However
this
is
not
an
integral
part
of
the
imperative
paradigm.
It
would
be
preferable
if
code
could
be
used
to
solve
related
problems
without
the
need
to
be
rewritten.
This
reusability
should
be
an
integral
part
of
the
paradigm
in
much
the
same
way
as
our
brain
uses
past
experience
to
solve
new
related
problems.
The
development
of
software
products
has
now
become
one
of
the
fastest
growing
industries.
This
was
not
the
case
a
mere
20-30
years
ago.
It
makes
sense
that
software
should
be
designed
so
that
code
can
be
reused
in
different
contexts
to
solve
different
problems.
Is
there
a
paradigm
that
will
encourage
the
reuse
of
code?
If
so,
them
the
task
of
software
developers
will
be
simplified
and
the
quality
of
the
resulting
products
improved.
Many
other
industries
reuse
components
in
a
variety
of
contexts.
For
example,
the
padding
in
a
lounge
chair
can
also
be
used
in
the
seat
of
a
car
or
to
provide
soundproofing
in
a
studio.
A
12-volt
light
bulb
may
be
used
in
a
torch,
on
a
boat,
in
an
airplane
or
in
a
car.
Sheet
aluminium
is
used
to
produce
soft
drink
cans,
lithographic
printing
plates
and
to
line
the
outside
or
air
transport
crates.
As
software
developers,
we
would
benefit
from
programming
languages
that
allow
us
to
reuse
software
components
in
a
similar
way.
EMERGING
TECHNOLOGIES
Adam Florence SDD HSC Notes
70
The
first
programmers
had
to
program
in
machine
language,
i.e.
binary.
The
programmer
was
forced
to
think
like
the
machine
and
the
language
was
dependent
on
the
processor.
John
Von
Neumann
was
using
his
student
to
convert
his
code
into
binary
machine
language
for
input
using
punched
cards.
Apparently
one
of
his
students
asked
why
the
machine
could
not
perform
the
conversion.
Von
Neumann
replied
that
the
resources
of
the
computer
where
far
too
valuable
to
be
wasted
on
such
menial
tasks.
Eventually
assembler
languages
emerged
to
perform
this
precise
task.
At
the
time,
assembler
languages
were
viewed
as
a
way
of
removing
the
programmer
from
the
technical
aspects
of
implementation
so
they
could
focus
on
solving
the
problem.
Compared
to
todays
modern
languages
assembler
is
extremely
primitive.
The
ever-increasing
speed
of
the
technology
underpinning
computer
hardware
has
allowed
programming
languages
to
further
remove
the
programmer
from
the
machine
code.
The
emphasis
is
on
creating
programming
tools
to
assist
in
the
development
of
software
products
without
the
need
for
the
programmer
to
directly
interact
with
lower-level
CPU
processes.
The
final
software
product
may
not
always
be
as
efficient
as
a
similarly
developed
machine
code
product,
however
its
development
is
certainly
a
simpler
and
more
intuitive
process.
The
imperative
paradigm
has
evolved
over
the
years
from
lower-level
languages
that
directly
accessed
the
computers
hardware
functions.
Computers
are
not
powerful
enough
that
different
ways
of
viewing
and
solving
problems
can
be
utilised.
In
the
next
section,
we
look
at
some
different
approaches
that
are
emerging
to
assist
in
the
solution
of
problems.
IMPERATIVE
Imperative
languages
use
sequencing,
decisions
and
repetition
as
their
main
problem
solving
methods.
Data
and
processing
are
separated
with
imperative
languages.
We
create
variables
for
data
storage
and
then
we
perform
processes
on
them.
The
programmer
must
specify
an
explicit
sequence
of
steps
to
follow
to
produce
a
result.
Concepts
of
imperative
include:
-
Control
structures
Variables
Array
Advantages
Disadvantages
- Efficient
execution
- Programmer
must
deal
with
management
of
- Easier
to
read
the
logic
variables
and
assignment
of
values
to
them
of
the
program
- Labour
intensive
construction
of
program
- Difficult
to
solve
certain
types
of
problems
- The
need
to
code
for
every
individual
process
- Difficulty
of
coding
for
variability
One
area
of
problems
suited
to
the
imperative
paradigm
is
business
applications.
These
applications
follow
a
clear
business
process,
which
can
be
programmed.
Imperative
languages
require
the
developer
to
understand
all
details
of
the
problem
and
to
be
able
to
solve
the
problem
completely.
Many
types
of
problems
do
not
have
precise
solutions
and
developing
an
algorithm,
which
solves
such
problems,
is
not
feasible.
LOGIC
PARADIGM
The
logic
paradigm
uses
facts
and
rules
as
its
basic
building
blocks.
The
logic
paradigm
is
used
to
develop
programs
in
the
area
of
AI.
Prolog
is
the
most
common
logical
programming
Adam Florence SDD HSC Notes
71
language.
It
is
short
for
programming
in
logic.
One
of
the
major
influences
on
the
nature
of
the
Prolog
language
was
the
need
to
process
natural
language.
Prolog
is
used
primarily
in
the
areas
of
AI
including
natural
language
processing.
Advantages
Disadvantages
- Logic construction that leads to
fewer errors and less maintenance
- Can be used on multiple processor
machines
- Good tool for prototyping
- Easier language to write and
maintain, because of declarative
style
- Suits AI problems with facts and
rules
- Easy to modify and add new facts
and rules
- Only operates on the logic within
the program and cant be
considered the perfect logic tool
- Code may not be as efficient to run
once coded compared to imperative
CONCEPTS
FACTS
Let
us
assume
we
have
a
simple
food
chain
where
lions
eat
dogs,
dogs
eat
cats,
cats
ear
birds,
birds
eat
spiders
and
spiders
eat
flies.
We
write
the
facts
as
follows:
eat
(lion,
dog).
eat
(dog,
cat).
eat
(cat,
bird).
eat
(bird,
spider).
eat
(spider,
fly).
QUERIES
Querying
these
facts
is
simple.
Say
we
wish
to
determine
if
a
spider
can
eat
a
dog.
We
enter
the
line:
?-eat
(spider,
dog)
When
we
run
the
program
(query),
the
Prolog
inference
engine
responds
NO,
where
as
if
we
enter
the
query:
?-eat
(dog,
cat)
The
output
would
be
yes.
In
Prolog
a
query
is
known
as
a
goal,
i.e.
our
goal
was
to
find
out
if
a
dog
could
eat
a
cat.
When
we
just
have
facts
in
our
database
and
no
rules
then
Prolog
merely
searches
through
the
facts
for
a
match.
If
a
match
occurs
then
our
goal
has
been
fulfilled
and
Yes
is
output.
If
no
match
is
found
then
our
goal
fails
and
No
is
output.
GENERAL
FACTS
Let
us
introduce
a
general
fact
into
our
program
to
say
that
everyone
like
eating
flies.
Rather
than
having
to
write
a
long
list
of
new
facts,
we
can
use
a
variable,
say
X
to
represent
any
value.
Our
new
fact
would
be:
eat
(X,
fly).
Variables
must
have
an
upper
case
first
letter.
Now
if
our
goal
is:
?-eat
(dog,
fly)
or
Adam Florence SDD HSC Notes
72
?-eat (lion, fly) or
?-eat (egg, fly)
the result will always be true. Let us further generalize by introducing a rule into our system.
Say that if a lion can eat a dog and a dog can eat a cat, then a lion must be able to eat a cat.
By continually applying this rule, we see that all animals will be able to eat flies so we can
remove:
eat (X, fly).
RULES, KNOWLEDGE BASE AND INFERENCE ENGINE
From our facts. Generalising this statement we get something as followed. If A can eat B
and B can eat C then A can eat C, we write this as:
eat (A, C) :- eat (A, B), eat (B, C).
As A, B and C are in upper case they are variables. Facts and rules combine to form a base, a
database containing all facts and rules. During execution of a goal, Prolog interrogates the
knowledge bases in an attempt to fulfill the goal.
As an example, we wish to know if dogs eat spiders. So we execute the goal:
?-eat (dog, spider)
And it yields the result Yes as expected. How is Prolog executing this goal? Firstly, the list of
facts is examined in search of a direct match; none is found. Next the rules are examined. In
our example, only one rule exists. This rule allows us to reduce our goal into two sub-goals:
eat (dog, X).
eat (X, spider).
We then examine the first sub-goal and compare it to our facts. The first and in this case the
only match is:
eat (dog, cat).
The first sub-goal is then fulfilled. For our original goal to be fulfilled we require the second
sub-goal:
eat (cat, spider).
To be fulfilled. Breaking this goal down using our rule, we get:
eat (cat, Y).
eat (Y, spider).
Examining our facts we find that bird fulfills Y. As a result of these inferences, the original
goal is fulfilled and Yes is output.
The inference engine carries out this processing. The inference engine is the processing unit
of logical programming languages. Inference engines apply the knowledge contained within
the knowledge base to reach conclusions about goals. They do this in an organized and
systemic manner.
The goal:
?-eat (bird, dog).
Should result in an output of No. But, Prolog reports this as a stack overflow. This is as the
inference engine approaches the resolution of the goal in the same way as above but will
keep trying until a stack overflow occurs, as no solution to the goal is found. This is a result
Adam Florence SDD HSC Notes
73
of recursion, repetition mechanism where a rule contains itself. A work-around is to create a
new rule based on the old rule. We call this new rule caneat, where a dog can eat a spider:
caneat (A, C):- eat (A, C).
caneat (A, C):- eat (A, B), caneat (B, C).
In our new goal:
?-caneat (spider, dog).
Using the first rule we get:
eat (spider, dog).
This is not a fact and cant be broken down. Examining the second rule gives us:
eat (spider, X) and
caneat (X, dog)
The facts indicate that X could be a fly, in which case we need to resolve:
caneat (fly, dog)
So the goal expands to:
eat (fly, Y) and
caneat (Y, dog)
At this point the addition of the new rule affects the operation of the inference engine, no
fact or rule exists in our knowledge base to resolve what a fly can eat. As a consequence to
output is No, birds cannot eat dogs.
BACKWARD AND FORWARD CHAINING
There are two common strategies used to resolve goals, backward chaining and forward
chaining. So far, the examples used a backward chaining strategy. We started with a goal
and sequentially searched through our knowledge base in search of facts and then rules that
could be used to prove our goal. If we found a fact that fit, then the goal was proved. If we
found a rule then we commenced our search once again at the start of the knowledge base
using the goals within the rule. The process continued until we either proved our goal or
reached a dead end.
Forward chaining uses almost the reverse strategy to backward chaining. When using a
forward chaining strategy we need to know some initial facts are true. We use these facts to
reach a conclusion. It is possible for forward chaining to result in more than one conclusion.
Prolog is able to use a combination of backwards and forward chaining; it depends on the
question and the facts and rules held in the knowledge base.
We have the following set of rules in regard to aircraft that we know to be true:
1.
2.
3.
4.
If
a
plane
has
a
jet
engine
and
a
single
seat,
then
it
is
a
jet
fighter
If
a
plane
has
a
jet
engine
and
a
pressured
cabin,
then
it
can
fly
above
15000
feet
If
a
plane
has
fixed
windows
then
it
has
a
pressurised
cabin
If
a
plane
can
fly
above
15000
feet,
then
it
must
be
air-conditioned
Suppose
we
wish
to
prove
using
these
rules,
that
a
jet
with
fixed
windows
must
be
air-
conditioned.
Let
us
examine
this
problem
using
firstly
a
backward
chaining
strategy
and
then
using
a
forward
chaining
strategy.
Backward
chaining:
Assume
the
theory
is
true
and
then
ask
questions
to
systematically
verify
the
necessary
rules
are
present.
Using
this
method
we
commence
with
out
desired
goal,
namely
to
prove
that
a
Adam Florence SDD HSC Notes
74
jet
with
fixed
windows
must
be
air-conditioned.
We
scan
down
our
rules
until
we
find
one
that
results
in
an
air-conditioned
plane.
Rule
4
meets
this
need.
This
rule
provides
us
with
a
sub-goal
to
prove,
namely
that
our
plane
can
fly
above
15000
feet.
Rule
2
meets
this
requirement.
Two
new
sub-goals
result:
the
plane
must
have
a
jet
engine
and
a
pressurised
cabin.
We
know
the
plane
has
a
jet
engine,
as
part
of
the
question.
Rule
3
proves
that
it
also
has
to
have
a
pressurised
cabin.
Out
theory
is
then
proved:
jets
with
fixed
windows
must
be
air-conditioned.
Forward
chaining:
Start
from
the
beginning
of
the
facts
and
rules
and
ask
question
to
determine
which
path
to
follow
next
to
arrive
at
a
conclusion.
Using
this
approach
we
use
the
knowledge
that
our
jet
has
fixed
windows
and
attempt
to
reach
a
conclusion.
We
find
rule
3
that
means
our
plane
must
also
be
pressurised.
So
our
plane
is
a
jet
with
fixed
windows
that
is
pressurised.
Using
this
information,
we
scan
our
rules
again.
We
find
that
rule
2
means
our
plane
can
also
fly
above
15000
feet.
As
a
consequence,
rule
4
becomes
relevant
and
our
plane
must
be
air-
conditioned.
Out
theory
is
once
again
proved.
LANGUAGE
SYNTAX
Each
of
these
questions
illustrates
different
Prolog
concepts
and
the
suggested
solutions
include
notes
to
further
explain
any
new
concepts.
QUESTION
1
Consider
the
following
Prolog
code:
member
(A,
[A|B]).
%Rule
1
member
(A,
[B|C]):-
member(A,
C).
%Rule
2
Square
brackets
are
used
to
denote
a
list.
A
list
is
a
data
structure
which
simply
groups
a
number
of
data
items
A
vertical
bar
is
used
to
separate
the
head
of
a
list
from
its
tail.
The
head
of
a
list
is
simply
its
first
item
and
the
tail
is
the
remaining
list
The
%
signs
is
used
to
begin
a
comment
a) Explain
how
the
goal
member
(5,
[2,5,4]).
Would
be
evaluated:
member(5,
[2,5,4])
=
member(5,
[2|5,4])
%matches
rule
2
=
member(5,
[5,4])
%new
goal
so
we
can
prove
rule
2
=
member(5,
[5|4])
%matches
rule
1
Hence,
the
goal
evaluates
to
True
b) Explain how the goal member (X, [2,5,4]). Would be evaluated:
member(X, [2,5,4])
= member(X, [2|5,4]) %matches rule 1 when X = 2
Hence, goal is True when X=2
Continuing
= member(X, [2|5,4])
= member(X, [5,4]) %new goal to prove
= member(X, [5|4]) %matches rule 1 when X=5
Hence, goal is true when X=5
Continuing
= member(X, [5|4])
= member(X, [4]) %new goal to prove
= member(X, [4| ]) %matches rule 1 when X=4
Adam Florence SDD HSC Notes
75
Hence, goal is true when X = 4
Continuing
= member(X, [4| ])
= member(X, []) %does not match anything
Hence, no more solutions
In summary, X = 2 and 4 and 5
QUESTION 2
The following rule has been defined:
dollar([A,B,C,D]) :-
member(A, [0,1,2]),
member(B, [0,1,2,3,4,5]),
member(C, [0,1,2,3,4,5,6,7,8,9,10]),
E is 50*A + 20*B + 10*C,
E =< 100,
D is (100-E)/5
New line for each clause within a rule, using commas to separate as well
The keyboard is is used to assign a value to a variable
a) The goal dollar ([1,2,0,2]) evaluates as true. Explain the processing performed as this
goal is evaluated:
Each
sub-goal
is
tested
in
tern.
A
is
1
which
is
a
valid
member
of
the
list,
same
for
B
and
C.
E
is
then
calculated
as
90,
which
is
less
thank
100
so
this
sub-goal
is
true.
Finally
(100-90)/5
is
2
which
is
the
D
value,
so
the
sub-goal
is
true.
b) Explain
why
the
three
member
sub-goals
are
required
within
the
rule:
When
a
goal
does
not
include
values,
then
the
inference
must
try
to
assert
values.
The
inference
engine
systematically
tries
each
value
in
the
list
of
possible
values
for
each
variable.
If
no
set
of
possible
values
can
be
asserted.
Without
the
3
member
clauses,
we
would
then
have
to
find
or
prove
the
values
for
A,
B,
C
some
other
way.
APPROPRIATE
USES
Prolog
is
the
leading
programming
language
for
AI
applications
and
research.
The
logic
paradigm
is
based
on
formal
predicate
logic,
which
has
historically
been
the
basis
of
much
research
into
how
humans
think,
reason
and
make
decisions.
In
logic
we
describe
the
problem
we
wish
to
solve
rather
than
describing
how
to
solve
the
problem.
The
logic
paradigm
is
particularly
good
at
representing
knowledge
and
then
using
this
knowledge
to
reason.
Often
the
reasoning
performed
by
the
inference
engine
is
essentially
pattern
matching.
This
pattern
matching
ability
is
used
for
a
variety
of
AI
applications
including
natural
language
processing
such
as
grammar
and
spell
checks.
It
is
also
used
to
simulate
the
reasoning
of
human
experts
within
expert
systems.
An
expert
system
is
used
to
perform
functions
that
would
normally
be
performed
by
a
human
expert
in
that
field.
A
doctor
may
use
an
expert
system
to
diagnose
illnesses
or
economists
may
use
an
expert
system
to
forecast
economic
trends.
In
general,
expert
systems
do
not
reach
definite
conclusions
rather
they
weigh
up
the
evidence
and
present
possible
conclusions.
The
reasoning
is
stored
in
a
knowledge
base
that
is
interrogated
by
an
expert
system
shell.
Expert
systems
use
facts
and
rules
to
reach
conclusions
using
similar
techniques
to
those
used
in
Prolog.
Many
expert
systems
also
allow
the
inclusion
of
heuristics.
These
are
rules
that
are
generally
accepted
as
true
within
the
particular
specialist
area,
heuristics
are
criteria
for
deciding
which,
among
several
alternative
courses
of
action,
Adam Florence SDD HSC Notes
76
promises
to
be
the
most
effective
in
order
to
achieve
some
goal.
Heuristics
are
often
described
as
rules
of
thumb.
Heuristics
are
what
give
expert
systems
a
human
feel.
ANOTHER
EXAMPLE
The
following
example
uses
a
family
database.
Some
facts
of
the
family
database
are:
female(X)
meaning
that
X
is
a
female.
male(Y)
meaning
that
Y
is
a
male.
parent(X,
Y)
meaning
that
X
is
the
parent
of
Y.
Some
examples
of
facts
for
this
database
are:
female(karen)
female(rosemary)
female(sun
yi)
female(mahdu)
male(sam)
male(steve)
parent(sam,
karen)
parent(rosemary,
karen)
parent(mahdu,
sam)
parent(steve,
sam)
parent(rosemary,
sun
yi)
Some
rules
for
the
family
database
are:
grandparent(X,
Y)
:-
parent(X,
Z),
parent(Z,
Y)
X
is
the
grandparent
of
Y
if
X
is
the
parent
of
Z
and
Z
is
the
parent
of
Y
sibling(X,
Y)
:-
parent(Z,
X),
parent(Z,
Y),
X
Y
X
is
the
sibling
of
Y
when
Z
is
the
parent
of
both
X
and
Y,
and
X
and
Y
are
different
people.
(ie
you
cannot
be
your
own
sibling).
Example
goals
for
the
family
database
are:
grandmother(mahdu,
karen)
this
would
evaluate
to
true
based
on
the
facts
defined
grandmother(mahdu,
steve)
this
would
evaluate
to
false
based
on
the
facts
defined
OBJECT ORIENTED PARADIGM
Object oriented languages are fast becoming the most popular of all languages. The
reusability of the code makes them an excellent choice for a large variety of applications.
Many traditional imperative languages have been updated by adding OO functionality. For
example C to C++, Java is another example of an OOP language.
Advantages
Disadvantages
- Promotes the reusability of code by - Greater planning needed
handing off responsibility for some - Runs slower
actions to other data classes
- Can produce a spaghetti approach
- Inheritance give OOP its chief
to problem solving
benefit, ease code reuse and
extension without the need to
change existing code
- The mechanism of modelling a
program as a collection of objects of
various classes, and furthermore
Adam Florence SDD HSC Notes
77
describing many classes as
extensions of other classes
CONCEPTS
OBJECTS
We wish to write a computer adventure game. The game has two distinct types of
characters, goodies and baddies. The goodies are players and baddies are automated things
that try to defeat the goodies. The aim is to collect all the treasure without the baddies
wiping you out. Baddies can be monsters, rooms or trees. Goodies move through a maze of
streets, parks and buildings trying to collect treasure.
Firstly, we need to design objects that will form the basis of our program. To do this we need
to understand what an object is. Objects contain attributes and methods. Attributes are
what an object knows and remembers, and methods are actions the objects can do.
Well need an object for each goodie and each baddie in the game. All the goodies will
require a personality, intelligence, agility and health. Similarly, all goodies need to move
around, get treasure and fight. We can design a class called goodie that describes a general
goodie. We can then use this class to create individual goodies for use in our game.
Lets say each attribute is represented using an integer from 0 to 10. Lets consider a
particular goodie for a moment, called Mr Nice. Mr Nice starts the game with the following
attribute values: personality =3, agility = 4, intelligence = 8, health = 7. If he gets in a fight
with a baddie, he might lose health. If he outwits a baddie or finds treasure, his intelligence
may increase.
ENCAPSULATION
The values of Mr Nices attributes can only change as a result of one of his methods altering
the attribute. This concept is known as encapsulation, the process of hiding an objects data
and processes from its environment, only the object can alter its own data. Mr Nices
attributes are private and are contained within him. In OO terms, encapsulation means that
objects control their own private attributes using their methods. No other object can alter
another objects attributes directly, rather they must use the objects public methods.
Encapsulation is a vital concept in OOP. It allows the creation of robust and reusable classes
of objects. As programmers, we know that if an attribute has changed then the object must
have made the change itself, a great help when testing and debugging programs.
CLASS
A class is the definition of a category of objects, the class defines all the common attributes
and methods of the different objects that belong to it. We can design a class called goodie
that describes a general goodie. We can then use this class to create individual goodies for
use in our game. We will also need a class for baddies. A class will define each object, and an
object is an instance of a class.
Use the goodies class to create an instance of a good, e.g. Mr Nice. The class definition tells
Mr Nice what attributes he has and how to accomplish his methods. In the following we
declare a goodie class with the following code:
public class Goodie {
private -
personality: int
agility: int
intelligence: int
health: int
Adam Florence SDD HSC Notes
78
public
-
move()
{
}
fight
()
{
}
getTreasure
()
{
}
Creating
an
object
based
on
a
class
is
called
instantiation.
The
following
code
instantiates
the
object
Mr
Nice
and
Mrs
Lovely:
Goodie
Mr
Nice
=
new
Goodie()
Goodie
Mrs
Lovely
=
new
Goodie()
INHERITANCE
Inheritance
is
the
ability
of
objects
to
take
on
the
characteristics
of
their
parent
class
or
classes.
So
far
we
have
only
created
goodies,
our
program
requires
some
baddies
as
well.
The
baddie
class
declaration
would
be
similar
in
many
respects
to
the
goodie
class
declaration.
The
attributes
are
the
same
except
intelligence
is
removed
and
aggression
and
badType
are
added.
If
we
create
a
super
class
called
character,
this
class
could
contain
all
the
common
attributes
and
methods
used
in
both
goodie
and
baddie
classes.
This
is
the
concept
of
inheritance,
subclasses
inherit
all
the
attributes
and
methods
of
their
super
class,
and
subclasses
also
extend
the
super
class.
The
ability
of
a
class
to
inherit
features
from
other
classes
is
extremely
useful
in
OOP.
Because
each
class
has
been
developed
as
a
robust
unit
we
know
that
inherited
components
will
also
be
robust.
Development
of
new
objects
with
similar
characteristics
to
existing
objects
is
greatly
simplified
using
inheritance.
Following
are
the
amended
declaration
of
the
classes:
public
class
character
{
private
-
agility:
int
health:
int
}
public
-
move
()
{
}
fight
()
{
}
public class goodie extends character {
private -
personality: int
intelligence: int
}
public
-
getTreasure()
{}
public class baddie extends character {
private -
aggression: int
badType: int
}
public
-
makeNoise
()
{}
ABSTRACTION
Adam Florence SDD HSC Notes
79
The
process
of
designing
objects
by
breaking
them
down
into
component
classes
allows
us
to
concentrate
on
the
details
of
our
current
work.
This
is
the
process
of
abstraction.
The
hierarchy
of
classes
is
designed
in
such
a
way
that
each
class
is
reduced
so
as
to
include
only
its
necessary
attributes
and
methods.
Abstraction
allows
us
to
isolate
parts
of
the
problem
and
consider
its
solution
apart
from
the
main
problem.
Encapsulation
and
inheritance
greatly
assist
in
the
process
of
abstraction.
They
allow
us
to
put
the
overall
problem
aside
with
confidence
whilst
sub-problems
are
dealt
with.
CONSTRUCTORS
In
OOP
you
cannot
just
assign
values
to
attributes.
For
example,
you
cant
say
MrNice.health=7,
this
this
would
contradict
the
concept
of
encapsulation.
Encapsulating
attributes
within
objects
is
achieved
by
specifying
that
each
attribute
is
private.
Only
the
classes
methods
can
change
the
value
of
attributes.
To
initialise
the
value
of
an
objects
attributes
requires
a
special
type
of
method
called
a
constructor.
Every
time
an
object
is
instantiated
its
constructor
method
is
executed.
If
you
havent
written
a
constructor,
then
the
compiler
creates
a
dummy
one
for
you.
If
we
want
all
our
baddies
to
be
created
with
both
agility
and
health
set
at
5,
and
also
want
to
be
able
to
create
baddies
of
different
badType
with
different
amounts
of
aggression.
Constructor
methods
always
have
the
same
name
as
the
class.
Following
are
our
class
declarations
with
constructors
that
perform
the
task:
public
class
character
{
private
-
agility:
int
health:
int
}
public
character(int
a,
int
h)
{
if
(a<0
||
a>10)
a
=
0;
this.agility
=
a;
if
(h<0
||
h>10)
h
=
0;
this.health
=
h;
}
move
()
{
}
fight
()
{
}
public class baddie extends character {
private -
aggression: int
badType: int
public
baddie
(int
a,
int
b)
{
super
(5,5);
if
(a<0
||
a>10)
a
=
0;
this.aggression
=
a;
if
(b<0
||
b>10)
b
=
0;
this.badType
=
b;
Adam Florence SDD HSC Notes
80
}
makeNoise
()
{}
In
the
above
this
is
used
to
specify
the
current
object,
and
super
is
used
to
refer
to
public
items
in
the
super
class.
To
create
a
baddie
object
called
crazyTree
with
agility
and
health
of
5,
aggression
of
3,
and
a
badType
of
2:
Baddie
crazyTree
=
new
Baddie(3,2)
METHODS
public
class
goodie
extends
character
{
private
-
personality:
int
intelligence:
int
public
-
getTreasure()
{
int
h
=
this.getHealth()
this.setHealth(h++)
int
p
=
this.getPersonality
this.setPersonality(p++)
}
getHealth()
{
return
this.health
}
getPersonality()
{
return
this.personality
}
setHealth(int
h)
{
this.health
=
h
}
setPersonality
(int
p)
{
this.personality
=
p
}
}
If
someone
is
playing
the
adventure
game
and
they
find
a
piece
of
treasure.
The
command
mrNice.getTreasure()
gets
executed,
and
then
health
and
personality
are
incremented.
POLYMORPHISM
Generally
polymorphism
is
the
ability
to
appear
in
more
than
one
form.
In
terms
of
OOP,
polymorphism
refers
to
the
ability
of
the
same
command
to
process
objects
from
the
same
super
class
differently
depending
on
their
subclass.
At
runtime
the
system
chooses
the
precise
method
to
execute
based
on
the
subclass
of
each
particular
object
being
processed.
Polymorphism
allows
programmer
to
process
objects
from
a
variety
of
different
subclasses
together
efficiently
within
loops.
For
example
when
using
shapes,
the
subclass
method
getArea
would
be
different
for
circles
and
rectangles.
APPROPRIATE
USES
Used
in
cases
where
there
are
related
classes
of
data
that
lend
themselves
naturally
to
a
class
hierarchy.
This
is
often
games
or
programs
with
a
high
amount
of
interaction
e.g.
MS
word.
OOP
languages
are
used
in
computer
games
and
web-based
database
applications.
ANOTHER
EXAMPLE
Adam Florence SDD HSC Notes
81
class
Point
{
private
point_no:
integer
x_coordinate:
double
y_coordinate:
double
public
getPoint(point_no):
return
x_coordinate
and
y_coordinate
}
sub-class
Circle
{
is
a
Point
private
circle_no:
integer
radius:
double
public
getArea(circle_no):
return
Math.PI*radius*radius
}
sub-class
Rectangle
{
is
a
Point
private
rectangle_no:
integer
height:
double
width:
double
public
getArea(rectangle_no):
return
height*width
}
The
software
used
must
allow
students
to:
define
classes,
objects,
attributes
and
methods
make
use
of
inheritance,
polymorphism
and
encapsulation
use
control
structures
and
variables.
EFFECT ON PROGRAMMERS PRODUCTIVITY
An overriding motivation for introducing programming languages based on different
paradigms is to increase the productivity of programmers. Different problems require
different sets of tools to enable the production of efficient and reliable solutions. The effect
of using languages more suited to particular tasks has an effect on productivity.
Management must weigh up the positive and negative effects when deciding on a choice of
language to be used for particular projects.
SPEED OF CODE GENERATION
Adam Florence SDD HSC Notes
82
The speed at which code can be generated is a traditional method of measuring a
programmers productivity. Many software companies still pay programmer based on the
number of lines of code they write, although this has mostly been phased out. Nevertheless,
the speed at which a programmer can create code to solve a problem is a valuable measure
of productivity.
Programming languages that increase the speed of code generation must increase the
productivity of programmer. Similarly, using a language based on a more suitable paradigm
will also increase the speed of code generation. Choosing the most suitable paradigm can
make the process of software design and code generation more efficient and will result in a
more elegant and useable final solution.
APPRAOCH TO TESTING
Module testing is perhaps where the largest productivity gains can be made. This is the case
when using OOP. These languages force programmers to write self-contained classes. These
classes can be thoroughly tested without requiring reference to other components.
Once a class has been created it is possible to create subclasses from the original. This ability
means that much of the code produced within new software projects will be tried and
tested code from previous efforts.
EFFECT ON MAINTENANCE
Maintenance is primarily about the ability of the code to be modified to meet changed
requirement. To modify code requires locating the section of code that requires
modification and then actually implementing the changes within the code. This requires
thorough documentation throughout the software development cycle but particularly at the
design and implementation stages.
Isolating the precise location of the code to be altered can be a time consuming and difficult
task, particularly for large applications. Languages that force programmers to modularise
their work greatly assist maintenance programmers to locate particular procedures and
functions with in the source code. OO languages do this well, imperative and logical
languages certainly provide the facility but it is not enforced. Ultimately no matter what
language is used, programmer can write well structured, elegant and readable code and
they can also write rubbish.
Robust, bug-free code is the desire of all software companies for it minimises maintenance
issues. Logical languages such as Prolog operate at a higher conceptual level thus removing
the programmer from the technical details at the CPU level. The responsibility for managing
memory and CPU operations is removed from the programmer and handed to the language
and its developers
EFFICIENCY OF SOLUTION ONCE CODED
Efficiency of software once it is coded is often measured in terms of speed. How fast can an
application retrieve a record, process it and store the result? How many CPU cycles does it
take for a ward processor to prepare a ten-page document for printing? These types of tests
are designed to test the efficiency of the final solution.
Imperative languages are based on the Von Neumann architecture. They have evolved in
line with the developments in hardware technologies. Many of these languages, e.g. C,
enable the programmer to work closely with the CPUs operations. Well written C programs
will out-perform most similar programs written using OOP or logic. Unfortunately this is a
consequence of the development and evolution of hardware technologies rather than
software technologies. Essentially languages using other non-imperative paradigms are,
crippled by the hardware. They are not able to compete on an even playing field.
Adam Florence SDD HSC Notes
83
The
good
news
is
that
languages
can
considerably
reduce
development
times.
In
addition,
hardware,
although
not
designed
for
these
paradigms,
is
now
capable
of
executing
applications
at
such
a
speed
that
efficiency
concerns
are
often
of
reduced
importance.
This
is
particularly
true
of
many
popular
OOP
languages
such
as
Java
and
C++.
LEARNING
CURVE
Programming
languages
based
on
the
logical
programming
paradigm
have
not
gained
wide
acceptance
amongst
the
general
software
development
community.
They
are
often
viewed
as
obtuse
and
specialised.
It
is
a
difficult
task
to
thoroughly
learn
languages
based
on
new
paradigms
and
often
the
learning
curve
is
steep.
The
benefits
however
are
often
greater
than
first
envisaged.
OO
languages,
on
the
other
hand,
are
accepted
and
used
by
a
large
proportion
of
software
development
companies.
Adam Florence SDD HSC Notes
84
You might also like
- PEM 2023 Investigating Science Trial HSC ExaminationNo ratings yetPEM 2023 Investigating Science Trial HSC Examination24 pages
- Lesson Plan in Science 6 Components of Ecosystem100% (1)Lesson Plan in Science 6 Components of Ecosystem5 pages
- Module 1 Topics: 1. The Evolving Role of SoftwareNo ratings yetModule 1 Topics: 1. The Evolving Role of Software51 pages
- Part I - Sample Questions: COMPETENCY 1: Patient CareNo ratings yetPart I - Sample Questions: COMPETENCY 1: Patient Care20 pages
- I, Hereby Declare That The Research Work Presented in The Summer Training Based Project Report Entitled, Study of Compotators of Frooti JuiceNo ratings yetI, Hereby Declare That The Research Work Presented in The Summer Training Based Project Report Entitled, Study of Compotators of Frooti Juice98 pages
- Chapter: 9.8 HTML Images Topic: 9.8.1 HTML Images: E-Content of Internet Technology and Web DesignNo ratings yetChapter: 9.8 HTML Images Topic: 9.8.1 HTML Images: E-Content of Internet Technology and Web Design7 pages
- By Mrbrightside: Software Design and Development - HSC Course Notes100% (1)By Mrbrightside: Software Design and Development - HSC Course Notes72 pages
- Strategic Value Management - Michael ThiryNo ratings yetStrategic Value Management - Michael Thiry8 pages
- Exaugural Speech by Outgoing President Ronaldo NiloNo ratings yetExaugural Speech by Outgoing President Ronaldo Nilo1 page
- CSIR CLRI Junior Secretariat Assistant Paper II 2018 EnglishNo ratings yetCSIR CLRI Junior Secretariat Assistant Paper II 2018 English24 pages
- Overview of Notes For Science and Technology50% (2)Overview of Notes For Science and Technology30 pages
- PressRelease-2013-Recall All ICs Issued in Sabah and Issue A New Sabah IC - 03 November 2013No ratings yetPressRelease-2013-Recall All ICs Issued in Sabah and Issue A New Sabah IC - 03 November 20132 pages
- Jacaranda Chemistry Chapter 6 (Indicators)100% (1)Jacaranda Chemistry Chapter 6 (Indicators)14 pages
- Preliminary Software Design and Development Preliminary Assessment Task 4100% (2)Preliminary Software Design and Development Preliminary Assessment Task 48 pages
- Big Ideas For Design & Technology A Working PaperNo ratings yetBig Ideas For Design & Technology A Working Paper18 pages
- Unit 2 Global Information: Cambridge Technicals Level 3 Cambridge Technicals Level 3No ratings yetUnit 2 Global Information: Cambridge Technicals Level 3 Cambridge Technicals Level 318 pages
- Seminars - 09-12-2022 - Vanessa AQUINO CHAVESNo ratings yetSeminars - 09-12-2022 - Vanessa AQUINO CHAVES3 pages
- Software Design and Development HSC Half Yearly NotesNo ratings yetSoftware Design and Development HSC Half Yearly Notes6 pages
- Newington 2013 Economics Prelim Yearly & Solutions PDFNo ratings yetNewington 2013 Economics Prelim Yearly & Solutions PDF27 pages
- PDS AlphaTec MANUAL PRESSURE TEST KIT 2003No ratings yetPDS AlphaTec MANUAL PRESSURE TEST KIT 20031 page
- NSS Exploring Economics 5 (3 Edition) : Revision NotesNo ratings yetNSS Exploring Economics 5 (3 Edition) : Revision Notes2 pages
- Themes in Othello Theme Characters and Plot Examples Supporting Quote/sNo ratings yetThemes in Othello Theme Characters and Plot Examples Supporting Quote/s1 page
- IBS Index AIR1CA Atul Sir Book V2 Unofficial V2 1727813243638No ratings yetIBS Index AIR1CA Atul Sir Book V2 Unofficial V2 172781324363814 pages
- Software Design and Development Prelim NotesNo ratings yetSoftware Design and Development Prelim Notes5 pages
- Discuss How Christianity Enables Adherents To Respond To The Enduring Question of Human ExistenceNo ratings yetDiscuss How Christianity Enables Adherents To Respond To The Enduring Question of Human Existence2 pages
