Sdd HSC Summary

SDD HSC Social & Ethical Issues Page 1 of 43

HSC
Software Design
and Development

Mindmaps
and
Summary Sheets


E nti ced to u p gra de a pp l i ca ti on Resp on se to Pro bl e m s
Cro ssgra d e b y co mp e ti n g p ro du cts Q ua l i ty Id en ti fy the d eve lo p me n t p ro bl e m
In cre ase co m pu ter p owe r, sto ra g e & re li a b il i ty Und e rsta nd the d eve l op me n t p ro bl e m Cod e o f Co n du ct
o utp u t d e vi ces e ase of u se Desi g n & Te st a sol u tio n A ckn owl e dg e a l l co n tri b u to rs
con si ste n cy o f u ser Imp l e me nt th e sol u ti on Cle a ran ce to use co p yri g hte d m od u l es
i n te rface o f co de
Imp ro ve cu rren t ap p i ca ti on
d ocu me n ta ti on P ri va cy, secu ri ty of d ata secrets
In tro d uce n e w i n no vati o n sftwa re
a dh e re to sftwre sta n da rd s Use o f a p pro pri a te p rom pts
M ai n ten a nce , su pp o rt o f exi sti n g
p rod u ct

P re ve nti o n o f sp rea d of viru ses
G ov't, B u si n e ss, Ind i vid u al s S ca n re m ova bl e me di a be fo re u se Rel i a bi l i ty
Dri ve n b y m o re sop h i sti cate d Care ful vetti n g o f e m ai l P erfo rm wi th ou t fai l u e
h ard wa re & p eri p he ral s Not mi xi n g h om e /wo rk a pp l i cati o ns T ho rou g hl y che ck i n pu t da ta
M ai n tai n i ng ma rke t p osi tio n L ate st vi rus d efi n iti o n s K ee p to we l l de fi ne d & stan d p ro ce ss fo r
E ffe ct o n ma rke tpl a ce sftwre d e vl o p me nt
Rig h ts
Resp on si bi l i tes
S oftware o f De ve l o pe r
M arket
Nati o na l / In tern ati o n al L eg a l A cti o n
In te l l ectu al P ro p erty Y ea r 20 0 0 p rob l em
P la g i ari sm Com pu te r vi ruse s
S ha rewa re S oci a l & E xa m pl e s Rel i a nce on so ftwa re -> mi crowa ve
P ub l i c Dom a in P ira cy & E th i cal
O wn e rsh i p vs L i cen si ng Cop yrig h t Issu e s
Cop yrig h t L a ws
Reve rse En g i ne e ri n g
Deco mp i l ati o n Reu se o f exi sti n g m o du l es i n
L i ce n se Co n di ti o ns 4 th G en e ra ti on L an g ua g es
Network u se In fo rma ti on g ath eri n g to ol
P ro j e ct scop e i s con stra i n ed
P ira cy & co p yri g ht l a ws E vo l ves i nto ful l y wo rki n g
A uto ma ted too l s use d
Cop yrig h t l a ws & li ce nse ag ree m en ts p rog ram

Defi n e th e p rob l em Con stra i n ts: Data Fl o w
P la n th e so l u ti o n Fi na n ci a l Dia g ram
B ui l d th e so l uti o n O pe rati o na l IPO Ch a rt
Che ck th e so l uti o n T ech ni ca l A lg o rith ms
M od i fy th e so lu ti on S ch e du l i ng S yste m Flo w

Development & S tru cture d A pp ro ach
P ro to typ i ng
Dire ct co nve rsi o n
P ara l le l con versi on
Rap i d A p pl i cati o n d e ve l op m en t P ha sed con versi on
Implementation of E nd -use r de vel o pm e nt
Com bi n a ti o n o f Ap p roa che s
P il o t Co n ve rsio n

Software Solutions M eth od s of •Ou tsou rcin g
A pp roa ch es: Imp l e me nta ti on Form al to A d -h o c
G ea red to su pp o rt sp eci fi c Com me ri ca l System s
P op u la r Ap p roa che s:
a cti vi ti e s of the S yste m Dev. A cce ssi b l e to l a rge n um b er o f e mp l o ye e s
S oftware T re n ds i n S o ftwa re
Cycl e e g : S ma l l e n d u sers: off the she l f
CAS E T o ol s Deve l op me n t Deve l op me n t
T ext ed i ti ng , te st-d a ta g e ne rati o n, P op u la r l an g ua g es
d ocu me n t p rep a rati o n, fl ow ch a rt. A pp roa ch es
E mp l oym en t Tre nd s
V ersi on i n g: v1.0 v1 .1 v1 .3 v2 .0 Networke d so ftwa re
Data di cti on a ry O ff th e sh el f Pa cka g e s


Concept: Social & Ethical Issues: Concept: Social & Ethical Issues: Concept: Social & Ethical Issues:
Rights responsibilities of software developers Responsibilities continued: Responsibilities continued:

code of conduct / practice: quality: measured by a number of criteria: prevention of virus spread:
§ acknowledge all contributors § reliability § scan removable media before use
§ clearance to use copyrighted modules of code § ease of use: comfort of the user § careful vetting of email
§ one should not discuss employer’s or clients § consistency of user interface: placement of similar § not mixing development on home & work
requirements or specifications without consent items in the same place machines
§ one should maintain the privacy of individuals § documentation: process & product are of high § use latest virus definitions
§ one should use non-threatening prompts or quality
message boxes. § sticking to software standards Some issues for developers:
§ portability
reliability: the ability to perform without failure. response to problems: overcome problems in an order- § backward compatibility
§ thoroughly check input data ly fashion. § modularity
§ keep to well defined & standard processes for § identify the problem § security
software development § understand the development problem § cost constraints
§ design & test a solution to the develop. problem § operational reliability with other common software
§ implement the solution

Issue: Rights of software developers: Responsibilities of software developers: Concept: Social & Ethical Issues:
Piracy & copyright:
Authorship Protection of their product against theft & Acknowledge authors & sources particularly in a devel- intellectual property: a personal ownership of the
modification opment team creative ideas that develop from someone’s mind.
Reliability Protection against operating system, Check that the product works with the hardware & OS
hardware, & program problems which that they specify. Ensure there are no run time errors plagiarism: the theft of ideas & expressions of another
may make their product unusable. when installed & run as directed. person. Often code is collected for a range of other
Quality Codes to ensure others develop programs Use thorough testing procedures & error checking code sources.
that follow the same high standard Meet the user’s expectations as much as possible
Response Not to be harassed with trivial problems Provided troubleshooting manuals, online help. Provide shareware; software that is distributed for trial use
to prob- that could have been solved by the user customer support. Quick response to major or critical before purchase.
lems reading the documentation. problems. Make bug fixes freely available to users.
Code of All developers follow the same ethical Follow the standards set by members of the profes- public domain: freeware which can be copied &
conduct standards. sional association to which they belong. distributed freely. No payment is due. Still covered
Viruses Protection of the developer’s products by Ensure they do not distribute viruses with their by copyright.
users through the use of good current products or as part of their customer contact such as
antivirus products through emails. ownership vs. licensing: payment means the purchaser
has the right to use the software but NOT the owner-
ship of the software


Concept: Social & Ethical Issues: Concept: Social & Ethical Issues: Concept: Social & Ethical Issues:
Piracy & copyright: continued: Software piracy & copyright laws Software Market:
reverse/backward engineering: the process of reading Warez commercial packages that have been illegally § gov’t, business & private individuals make up the
source code & translating it to an algorithm which then copied or pirated & made publicly available. Pirateers software market.
can be modified & recoded elsewhere. have found a way to by-pass the copy-protection. § gov’t, businesses are more likely to need custom
§ distribution within Australia is illegal written software
decompilation: where object code is translated into § deprives the legitimate copyright owners of money § software market driven by more sophisticated
code that can be more easily studied by a programmer § some nations have refused to sign a universal hardware & peripherals. eg. as computers became
needing to understand the processes carried out. copyright law more powerful, word processing features advanced.

licence conditions: spells out exactly how the software relationship -> copyright laws & licence agreements: maintaining market position: aim is to make a profit.
may be used by the licence purchaser. It is a legally § licence is a contract § improve the current application
binding contract. § single-user licence § introducing new & innovative software applications
§ multi-user licence § maintenance & support is very important for sur-
network use: many programs are available for network § network licence vival of a software company
use. Licence indicates how many may use it or it may Business Software Association of Australia § active research & development program in major
be a site licence. § educate people software development companies.
§ centralized: single copy on central server § assist in software management § reputation as an ethical developer
§ distributed:individual copies on individual machines § help prosecute those in breach of licence agreemnt § bug-free software (or as close as possible)
Concept: Social & Ethical Issues: software market Concept: Social & Ethical Issues: software market
Effect on the market place Significant social & ethical issues:
Definition: software production is a multi-billion
dollar industry. National & international legal action resulting from
Summary Points: News Article: Y/N software development:
§ trumpet software vs OzEmail: OzEmail distributed
§ enticed to update their applications Winsock with their distribution disks but failed to ad-
§ crossgrade: change to a competing product eg. vise customers they had to register with Winsock. Bibliography:
go from Word to WordPerfect word processor Some documentation was omitted or chaned. OzEmail Main: Folwer’s HSC SDD text
§ more complex software needs more computer was ruled against. Supplementary: Wilson’s HSC SDD text
power. § Microsoft operating system & Internet Explorer
§ Sega vs Accolade: Accolade was within its right
to reverse engineer as it had not stolen Sega’s
creative works & only needed the secret codes for
Accolades games to work on Sega machines.
Example: eg. gaming, video editing, digital editing
More hard disk storage, RAM & processing speed Public issue:
§ Y2k millennium bug
§ computer viruses

SDD HSC Software Development Approaches Page 5 of 43

Concept: Software Development Approaches: Concept: Software Development Approaches: Concept: Software Development Approaches:
Approaches: commercial systems: structured approach continued structured approach continued:
structured approach: follows the software develop. § it takes little to fix a mistake at this stage but be-
cycle. It looks at the whole problem & divides it into comes more expensive in the latter stages building the solution: the programming, coding &
steps that can be systematically followed to arrive at a § feasibility of a software solution (constraints) testing phase. Everyone is involved.
solution. § top-down approach / step-wise refinement
§ it is time consuming but appropriate for complex planning the solution: involves a further, more in § peer checking, desk checking
problems. depth understanding of the needs of the users & § runtime testing
§ often a team is involved: system analyst, program- a choice of a method(s) to solve the problem.
mers, graphic designers, managers, trainers, users § planning the data & program structures checking the solution: a continuous part of the SDC
§ designing algorithms (system development cycle).
structured approach: § planning the user interface § acceptance testing: measured against the original
define the problem-> plan the solution-> build the § scheduling the project – Gantt chart specifications
solution-> check the solution-> modify the solution § choosing a programming language § real data used
§ dataflow diagrams, IPO charts used as tools § alpha / beta testing
define the problem: thoroughly understand & define § mostly involves the design & checking of § screen design, intuitive
the problem itself. algorithm & interfaces § staff training
§ interviews, collect data, observation, documents, § error handling within the program
questionnaire, surveys
§ specific requirements drawn up
structured approach: continued: structured approach: Advantages structured approach is used when:

modifying the solution: modifying the solution from § easier to write because it is broken into chunks § project is large scale, complex & is best solved
checking the solution. Further testing takes place on § easier to understand because of the use of using modularisation
the modifications. Program is either accepted or modi modules; can be easily tracked & connections seen § development budget is large
fied further. § easy to test & debug each module separately § time available is considerable
§ significant changes at this stage can be quite § easy to modify because only some modules need § a easy program to debug, write, understand &
expensive to be changed. modify is required.
§ should only be carried out if small or crucial § a project development team is involved.
§ in extreme cases, the analyst could recommend
the SDC start all over again.


Prototyping Rapid Applications Development End-user development
Definition: involves building a working model that is Definition: any method of software design that uses Definition: where the user adapts existing software
evaluated by users. It generally has screens but little tools to quickly generate a program for a user. tools to suit their needs or to obtain a solution to a
processing. problem.
Summary Points: News Article: Y/N Summary Points: News Article: Y/N Summary Points: News Article: Y/N
§ it can become the actual solution § uses existing modules to create a solution § a larger number of programs allow the users to
§ can be used as an information gathering tool existing modules need little or no testing create their own solution
that can be used in another program § may reuse code § very informal, little documentation
§ useful where a lot of computer interaction is § may use CASE tools & templates § buttons & macros can be used to a limited degree
required eg. multimedia, internet § requirements of project are well understood § disadv. end users within the same organization
§ user gives feedback via a prototype § scope is well constrained, focused. often duplicate processes unknowingly.
§ reduced documentation & faster development § includes adding modifications to existing software
compared to structured approach. Use end user development when:
Use prototyping when: Use prototyping when: § development involves the user
§ development is small scale & small budget § very small team, low budget & minimal time § it involves existing software solutions
§ a smaller team needed § small scale projects § it involves very little cost or time
§ less time available § a small range of coding languages § it involves small problems
§ help develop another program
Combination of approaches Methods of implementation Methods of implementation Adv. & Disadv.
parallel: the old & the new program work together for parallel adv: 2 programs can be compared. Fixing is
§ Using combinations of the 4 approaches can be a period of time. simpler because old one can be used in emergency
carried out. parallel disadv: user stress both systems operated.
§ eg. the problem could be split in two & the direct cut-over: the new program immediately replaces Confusion between programs. Dual costs - more
sections worked on separately using different the old program expensive. Large changes in procedures can cause
approaches. confusion.
phased: one or more tasks of the new program are direct adv: reduced implementation costs. Less pres-
§ The ultimate objective is always to produce a gradually implemented until the new program takes sure on users – only 1 program in place
properly documented solution to the problem. over all tasks of the old program. direct disadv: data transfer done quickly. No fallback.
User stress in training before new program in place.
pilot: one section of the organization uses the new phased adv: each task individually tested. Training is
program & all other sections continue with the old easier
program until a decision is made to put the new phased disadv:difficult to separate the old & new tasks
program into place across the whole system. longer time to bring online increases costs.
pilot adv: risk confined. Fixing problem is easier as old
program is still available.
pilot disadv: larger organizations (banks) required to
use this method. Multiple sites doing same task.


Trends in software development: Trends in software development continued: Networked software
outsourcing: hiring an outside organization to handle popular languages: Definition: software written for use on centralised
all or part of software serverices. § structured environments: C++, Visual Basic, Java networks. Needs to interact with the network oper-
§ no expense of a full Information Tech. department § informal: spreadsheets, web page,macro recording ing system which handle the security & communi-
§ effective use of scarce technological assets databases, SQL cations tasks.
§ difficulty of breaking unsatisfactory contracts § 3rd generation: COBAL & Fortran still popular Summary Points: News Article: Y/N
§ may not understand the ethos of the organisation § they all have a formal set of rules called syntax § business moving toward personal computers that
§ may feel it lost its control of is system § all use constants, variables & operators are networked.
§ some are easier to use than others and some run § security is of particular importance especially with
popular approaches: ranges for ad-hoc to formal. faster than others. financial transactions & the Internet.
§ web-page editors have encouraged end users Network software:
§ customising off the shelf software Employment trends: § user interface and the system
§ software accessible to large number of employees § less likely to be permanent employment § application: meets the needs of the end user
§ greater distribution of code libraries § will tend to be contract work to the business or § database management: manipulation & manage-
§ increasing use of hypermedia software development company ment of data on the network
§ increased use of authoring languages § increasingly high educational requirements § network: the means by which communications
takes place

Concept: Software Development Approaches: Concept: Software Development Approaches:
Customised off-the-shelf packages CASE tools
Definition: software that is purchased off the shelf & Definition: computer assisted software engineering to
can be modified to fit a scenario in a business eg. help in the task of software development & mainten-
book keeping software. ance.
Summary Points: News Article: Y/N
Summary Points: News Article: Y/N § general software to aid the software development
§ able to create a software solution from an inte- can be considered as CASE tools eg. word processor, Bibliography:
grated package eg. spreadsheets, Database, graphics, spreadsheet, graphics software Main: Fowler’s HSC SDD text
word processing § data dictionaries Supplementary: Wilson’s HSC SDD text
§ customizable interface § specialist software does exist but we have seen no
§ customizable reports practical examples.
§ conversion of old data to the new system § management of software development includes
§ lends itself to prototyping approach or an end- versioning the changes eg. v1.0->v1.1->1.1.1->1.2->
user approach. 1.3->v2.0
§ documentation generation using CASE tool
Example: MYOB, Creating a relational database for § test data generators CASE tool
a specific task. eg. Dean’s Merit Awards



Definition: Definition: Definition:

§ § §

§ § §

§ § §

Example: Example: Example:



§ § §

§ § §

§ § §


SDD HSC Defining & Understanding the Problem Page 9 of 43

O ve ral l Desi g n
S tru cture Ch arts
Data Fl o w Di ag ra ms
In cl u de s: mo du l e s & th e
IPO d ia g ram s
i n te ra cti o ns b etwee n m o du l es
L i ne a r storyb oa rd Id en ti fyi n g th e p rob l em
Hie ra rch i al storyb oa rd P ro b l em de fi ni ti on / fe a sib i l i ty stud y
Nee d s Data De si gn :
Network sto rybo a rd
O bj e cti ve s Id en ti fy d ata ob j ects
Hyb ri d storyb oa rd
Fea si bi l i ty Id en ti fy d ata typ es
S yste m fl owcha rt
Is i t worth S o l vi n g? Id en ti fy fi le stru cture
S cre e n d esi g n
Con stra i n ts Cro ss re fe re n ce
L i mi ted Pro totyp e
Deci sio n tre e B ud g eta ry co nsi d era tio n s
Deci sio n ta b l e O pe rati o na l co n sid e rati o ns S co p e:
S tru cture ch a rt T ech ni ca l co nsi d era tio n s How the softwa re fi ts in .
S ch e du l i ng Defi n es the b ou n da ri es
P ossi bl e Al te rn a tive s Form s o f in p ut/o utp u t
S oci a l & Eth i ca l co n si d e ra ti on s d ata
Defi n in g th e Pro bl e m
Descrip ti on o f p roce ssi n g
M od e ll i n g

S co p e o f th e pro j ect
Nee d to em p owe r th e u ser Desi g n S pe ci fi ca ti o n s Data de si gn
G ive s se n se of o wn e rsh i p S DC De fi ni n g & O ve ral l p ro g ram de si gn
A ckn owl e dg e u se r's p erspe cti ve Com mu n ica ti on Und e rsta nd i n g In te rface de si gn
A cce pti n g fe ed b ack th e P ro b l em P ro ce ss Desi gn
Cro ss-re fe re n ce with req u ire me n ts Imp l e me nt. / te stin g
d efi n i ti o n G en e ra l pro cesse s fo r
Imp l e me nta ti on & te sti n g te sti n g o utl i n ed .
Deve l op e r's Pe rspe ctive In sta l la ti on o nto si te is
Data typ e s care ful l y pl a nn e d
V ari a bl e s
A lg o rith ms P ro ce ss Desi gn :
Use r's p e rsp e cti ve E ach mo du l e d e scri b ed i n d eta i l

System Development Cycle: Descrip ti on o f th e In terfa ce
A lg o rith m th at d esri b es mo d ul e

Defining Understanding the
L oca l d a ta structure s
In te rface De sig n : A ny restri cti o ns / li m i ta ti on s
Hum an -ma ch in e in te rfa ce
Problem How the use r in te ra cts.
S pe ci fi ca ti o n s th at d escri be s
Cro ss Re fere nce :
E nsu res req u i re m en ts m et b y
th e i n te rface s b e twe en
software .
m od u le s, p ro gra m & extern a l
In di cate s wh i ch mo d ul e s m e et
d evi ces
p arti cul a r re q ui re me nts.

Dev.
Data typ e s: V ari a bl e s:
P ersp ecti ve :
Is a b l e to ca ter G lo b al , l oca l A lg o rith ms:
Con verts cl i e nt's
fo r stora g e A pp rop ri ate na m e o f B re a k d o wn p ro b l em
wish e s to a
V isu a li se d b y th e i tem i n to sma l le r pro b le m s.
p rog ram .
p rog ram me r & T op -town a p pro a ch
e xp re sse d a s a
m od e l o n p a pe r
Refl e ct th e d ata
i n th e p ro bl e m.


Concept: Define Understand the Problem: Concept: Define Understand the Problem: Concept: Define Understand the Problem:
Defining the problem: Determining the feasibility of the solution Determining the feasibility of the solution continued:
Definition: Problem definition involves examining the Definition: determines whether a problem is worth Possible alternatives: looks at all the other options
needs of the users, objectives that the solution is to solving. Constraint is a limitation placed on something. available to solve the problem.
meet, the boundaries within which the solution has to financial feasibility: the ability to develop a program § could include leaving the system unchanged
work and whether it is feasible. within the money allocated for the project. § rough cost of each alternative
§ the additional income &/or projected savings need § adv. & disadv. of each alternative
Needs: needs of the user, needs of the system (data to be more than the cost of implementing the solution. § analyst makes a recommendation with justification
types, storage of facts, perform certain processes & operational feasibility: refers to the skills & resources social & ethical considerations: impact upon people be
the output need). needed to complete and maintain the program. it lifestyle or work practices.
Objectives: are aims which are measurable. eg. maxi- § eg. artificial intelligence may be worthwhile but § right to privacy: sensitive personal information
mum response time. the skills don’t exist yet. § code from other sources need to be dealt with
Boundaries: where outputs leave one system & pass § meets the needs of the organization. May refine as per copyright.
on to the next system. a worker’s role.
§ are limits, borders technical feasibility: the availability of hardware and
§ can be hardware/software requirements software for the product to meet the needs of the
program.
scheduling feasibility: refers to time requirements.
Is it worth solving? There is usually a firm completion date. eg Y2K
bug.
Design Specifications: Overall program design: Interface design:
Definition: lays down the guidelines for development Definition: One steps back and takes a look at the Definition: the interface between the user & the
and give a yardstick to measure the success of the overall design of the program. Usually quite general. program.
project. Some aspects include: human-machine interface
§ structure charts: includes modules & the § give control of the program to the user
scope of the project: how the software fits in with the interactions between modules. § enable access to other parts of the program
whole system. § consistent screen design eg. navigation
§ forms of output / input § context / dataflow diagrams § simplicity: easy to learn and use
§ description of processing to convert input to output
§ any special processing needs § input processing output charts specifications: that describe the interfaces between
data design: identifies the data objects required & the modules, program and external devices. eg. printing
resulting data types. § system flow chart from a program
§ file structure & access covered here
cross reference: checking that data items are related
to their respective files / modules.


Process design: Implementation & testing: Developer’s perspective
Definition: a description of processing. Definition: implementation & testing needs to be Definition: white-box: is concerned with what hap-
planned out & specified before they are used. pens & how it happens. Input & output are equally
§ each module is described in detail. important.
§ a description of the interface. Includes machine- § general processes for testing outlined. data types:
human centered & machine-peripherals § installation onto the actual site needs to be § converts client’s wishes to a program
§ algorithm that describes each module carefully planned. § choose data types that cater for respective storage
§ identifies any local data structures within a module § visualised by the programmer & expressed as a
§ any restrictions / limitations on the module model on paper
§ data type has to reflect the data in the problem

variables: global or local variables may be used.
variable name should have meaning.

algorithm breaks a large problem into smaller pieces.
Uses the top-down approach or step-wise refinement.
Each module of algorithm should be given a meaning-
ful name.
Concept: Define Understand the Problem: Concept: Define Understand the Problem:
Modeling: Communication
Definition: a system can be represented in some way Definition: should interact with the user throughout
to show its structure. the process.
§ data flow diagarm
§ IPO chart Summary Points: News Article: Y/N
§ linear storyboard § it empowers the user
§ hierarchical storyboard
§ network storyboard: modules may be accessed § gives the user some sense of ownership Bibliography:
directly by other modules. Main: Fowler’s SDD HSC text
§ hybrid storyboard § acknowledges the user’s perspective Supplementary: Wilson’s SDD HSC text
§ system flow chart
§ screen design § demonstrates the ability to accept feedback.
§ limited prototype
§ decision tree
§ decision table
§ structure chart

Need to know how to construct DFD, system flow
chart, decision tree/table at least to some depth.



Concept: Define Understand the Problem:

SDD HSC Planning & Design Page 14 of 43

Id en ti fi ca ti o n o f ap p rop ri ate mo du l e s
S tru cture d P rog ram m in g In de n ti fi cati o n i n pu ts, p roce sse s &
Fun ctio n al Deco mp o si ti o n o utp u ts
Use o f M ai n mo d ul e T he sco p e o f va ri ab l es l o ca l pre ferre d
Use o f su b m od u l es P assi ng o f p a ra m ete rs
Wri tte n sep a rate l y T ho rou g h te sti n g
T este d se pa rate l y Desk ch e cki n g u si ng tra ce ta bl e s
System Development Cycle: S ho u ld b e i n de p en d en t Fi el d te stin g
Re-u se o f m o du l es P ro to typ i ng
Planning & Design M ai n ten a nce o n so m e E xte rna l do cum e nta tio n
m od u le s on l y n e ed e d In te rn al d ocu me nta ti on
L i sti n g a ssu m pti o ns

Deco mp o si ti on , reu sab i l i ty
P ro b l em So l vi n g Fun ctio n li b rari e s
S tra teg y Cal l , re tu rn me ch an i sms
Desi g n Con cep ts Fun ctio n an a to m y
Reco rds
Fun ctio n na me s
Data ba se te rmi n ol o g y
S DC Pl a nn i n g Fun ctio n in p ut
O bj e ct O rie n ted term in o l og y
Reco rds & & De sig n of M od u le s & Fun ctio n ou tpu t
Usi n g re cord s
Col l e cti o ns software Fun ctio n s Fun ctio n pro ce ssi ng
Neste d re co rds
sol u ti on s L oca l va rab l es
Col l e cti o ns
B oo l ea n fu n cti o n s
Defi n in g th e sto rag e
A rra ys (B asi c)
Defi n in g th e fu n cti o n s

S tri n g P roce ssi n g

S orti ng & S e arch in g Nam i ng , cre a ti n g a rrays
Hol d s si n gl e da ta typ e
A rra ys o f fi xe d l e ng th
S tri n g co nce pts: In de xin g arra ys
S ea rchi n g a rrays:
S tri n g m an i p ul a tio n fun cti o n s a re T ra ve rsi n g a rra ys
L i ne a r se arch
store d i n li b rari e s S wa p pi n g e l em e nts
B in a ry se arch
Con cate n ati o n o f 2 stri n g s Fi nd i ng l arg e st val u e i n arra y
S orti ng a rra ys:
tri mS tri n g Fi nd i ng p osi tio n of l a rg e st va lu e in a rra y
B ub b le sort
com p are Stri n gs S im p le l i ne a r se arch
S el e cti o n so rt
to Lo we rCase , to Up p erCase
In se rtio n so rt
stri n g Co n ta i n s
S ee Pow er Point
P re s enta tion


Concept: Planning & Design: structured Concept: Planning & Design: design concepts Concept: Planning & Design: design concepts
programming & functional decomposition identification of appropriate modules: identification of inputs, processes & outputs:
§ structured programming consists of a main module § read main module first to get overview of the Input:
which activates sub-modules. aka modular program- algorithm. Examine sub-modules to get more detailed § type of data?
ming (aka = also known as) information. § source of data?
§ functional decomposition: is the breaking down of § top-down: design main module first, then the sub § method of data input?
a complex problem down into functions. modules. also known as (aka) stepwise refinement § instructions to computer to handle data input?
§ a well written module can be used over & over Process data:
§ modules should be independent § what steps are taken to process the data?
§ are loops and/or selection structures needed?
Some requirements to generate software solutions: § instructions to computer to handle data
§ identification of inputs, outputs & processing processing?
§ id & definition of required data structures Output data:
§ an understanding where/when to use random § type of data output?
numbers § method of data output?
§ thorough testing of the solution § instructions to computer to handle data output?

IPO Chart

Concept: Planning & Design: design concepts: Concept: Planning & Design: design concepts: Concept: Planning & Design: design concepts
The scope of variables: it is preferred that variables continued: continued:
can only be used in the module in which they were field testing: give the completed software to a group of External documentation: documentation for the user in
created. (local variables vs global variables) people to try out under real working conditions. print form.
§ bugs are reported to the vendor
global variables: accessed by all modules at the same § bugs are fixed by the vendor & re-released with a Internal documentation: written within the algorithm
time without the need to pass their values around. higher version number. itself.
§ use of global variable often result in errors be- § it is frowned upon when software is rushed to § can be a written block of comments that appear
cause a module may unknowingly change the value. completion that still have numerable bugs. before the actual algorithm. Introduce the reader to
the algorithm & includes a brief description of its
thorough testing: one must provide sample input data prototyping: a partially complete software product. purpose.
values, run one’s algorithm using this data & check § usually contains a user-interface & some of the § can be single lines of comments embedded in the
that the output is correct. fundamental routines. algorithm at appropriate places.
§ allows client feedback § can use comments to break up the list of coding
desk checking: one keeps track of all variables & § cheaper than producing a full product for the sake of readability.
values on paper & adjusts the values as one goes line § allows one to clarify some of the requirements
by line through the algorithm. Test data: Listing assumptions: included in introductory
§ all branches must be tested as well as the § Legal & expected values comments. It tells readers what the algorithm
conditions of all loops. § illegal but expected values supports & what it omits.
§ use trace tables with desk checking § legal but unexpected values § eg.when reading data from a file, one may say
that you assume the file exist.


Concept: Planning & Design: Modules & Functions Concept: Planning & Design: Modules & Functions Concept: Planning & Design: Modules & Functions
General Issues Function anatomy Function anatomy continued:
decomposition & reusability: the algorithm is broken Definition: a function can have up to 4 parts. It must function processing: a function should do something.
down into smaller chunks. have a name & a block of instructions. It may have It does it something between keywords like BEGIN &
§ if correctly written, can be reused in other input and/or output but is not mandatory. END.
algorithms that have similar tasks: re-usable. function names: short, readable & meaningful. It tries
to indicate what the function does. eg.’findBiggest’ local variables: created within a function
function libraries: collections of well-tested & reusable § no conflict between local variables of one function
functions. function input: is the data passed to it by the calling and those of any other function.
§ functions within the library can be activated to do code. § are not shared
much of the processing. § also known as arguments or parameters. § the same name can be used in many functions
§ most programming languages have ‘standard
function libraries’ function output: we output information from a function Boolean functions: a Boolean value is either true or
by ‘returning’ it. eg. return bigNum false.
call and return mechanism: subprograms are activated § usually the last instruction in a function but not § a function that returns either true or false is called
by being called. Once the subprogram is finished it necessarily so. a Boolean function.
returns back to the place from which it was called. § when return is activated the function is ended at § called ‘query function’ because they usually
that instant. also known as: short circuiting perform a test on the value of their input.
§ often have a name starting with ‘is’ eg. isVoter

Concept: Planning & Design: Arrays: basic concepts Concept: Planning & Design: Advanced sorting & Concept: Planning & Design: String Processing
searching techniques Definition: string manipulation routines are found in
libraries.
concatenation: joins two or more strings together to
form one string.
trimString: removes all the spaces from the front &
rear of a string since users often accidentally types the
spaces in.
See Power Point Presentation See Power Point Presentation compareStrings: test the alphabetical order of two
on arrays on searching, sorting strings.
toLowerCase, to UpperCase: changes all the char-
acters of a string to lower or upper case. Should use
when accepting input from a user & comparing it to a
answer eg. Hangman, Sight Reading
stringContains: sees if one string is located inside
another string.
string insertion, string length, separation into
substrings

Concept: Planning & Design: Records & collections Concept: Planning & Design: Records & collections Concept: Planning & Design: Selection of language to
Definition: a record can hold more than one data collections: refers to the storage & management of be used.
type. A record has fields & each field is an array. several or many records. Event-driven software: uses actions to trigger an event
eg. Person is a record containing § collections are stored in an array of records for our eg. mouse click, key presses
name, a string purposes. Features: menus, buttons, other objects
age, a whole number Program logic: polling to check status of events; event
END Defining the storage: is an algorithm that creates an parsing to execute the events that are activated by the
array of records eg. 20 Stock records user (Wilson text)
§ a record encapsulates the two variables because Uses: games, GUI, computer controlled systems
the Person record is like a capsule. Defining the function: defines the fields of a record.
§ a record is the encapsulation of several variables sequential programming: follows a set of steps to solve
as fields in the one structure files: are blocks of data treated as single units a given problem.
§ the definition of a record is like a template that Features: standard control structures, variables used,
shows how a particular type of record is structured. sequential access: one must go through each record in assignment is to transfer data from one memory
sequence to get to it. Like a cassette music tape. location to another.
Nested records: we can use records within records. Program logic: order of execution is defined by the
Date is a record containing… random access: goes straight to the record location. programmer. Linear execution of instructions.
Person is a record containing a date (+ other fields) Like a music track on a compact disk. Uses: file & data handling programs such as word
processors, databases & spreadsheets.
Concept: Concept:

Definition: Definition:

Summary Points: News Article: Y/N Summary Points: News Article: Y/N
§ §
Bibliography
Mostly: Fowler SDD HSC text book
§ § Supplementary: Wilson SDD HSC text book

§ §

Example: Example:

SDD HSC Implementation Page 18 of 43

System Development Cycle:
T ech ni ca l Docu me n tati o n:
S ou rce cod e Hard wa re
Implementation
A lg o rith ms S oftware
Data Di ctio n ary E ffe ct o f em erg i ng tech n ol o gi e s
S yste ms do cum e nta tio n E ffe ct o n h u ma n e n viro n me nt Desi g n o f In d ivi d ua l scre en s
Futu re m ai n ten a nce of the cod e E ffe ct o n d e vel o pm e nt p ro cess Ide n tifi ca ti o n o f da ta re q ui re d
S oftware to a ssi st i n the DBM S ca n p rod u ce on scre e n
d ocu me n ta ti on p ro cess V B can d esi g n o wn scre en
CAS E to ol s Desi g n o f h e l p scre e ns
Hard wa re re q ui re me nts
A ud i en ce Id en ti fica ti on
Mi n i mu m co nfi g ura ti on
Con si ste ncy i n a pp ro ach
P ossi bl e ad d iti o na l ha rd wa re
E me rgi n g
A pp rop ri ate dri vers, exte nsi o ns
Form s o f do cum en ta ti o n : T ech no l og i e s
B NF, EB NF
P ro cess d ia ry Rai l roa d di a gra ms
Use r do cum e nta tio n Inte rface De sig n Mu l ti -d i me n sio n al a rra ys
Fun ctio n al d escri pti o n Hard wa re A rra ys o f re cord s
Insta l la ti on g ui d e E nvi ron me n t
Intro du ctory Ma n ua l L an g ua g e
S yste m A dm i n. ma n ua l Docu me nti o n S DC S yn tax
Ma ch in e co d e
Use r ma n ua l S oftware So l uti o n Imp l em e nta tio n CPU Instru cti o n fo rm a t
O nl i n e h el p o f S o ftwa re Rol e Use o f re gi sters a ccu mu l ato rs
S el f-do cum e nta tio n of the cod e S tru ctu re d a pp ro ach to a co mp l ex S ol u tio n s Cou n te r, fe tch-e xecu te cycl e
sol u ti on . A dd resse s o f ca l l ed rou ti ne s
O ne l og i ca l task pe r su b rou ti ne L in ki ng , use of DLL s
S tu b s
Fla g s P ro g ram
Isol a tio n of e rro rs Me th od s of T ra n sl a ti on :
Deve lo p me n t
Deb u gg i ng o utp ut state me n ts T ra n sla ti on Com pi l a tio n
T ech ni q ue s
E le g an ce o f so l u ti o n Me th od s Inte rpre tati o n
Wri ti ng for m ai n ten a nce Incre me n ta l i nte rpre tati o n
Dete cti n g & co rrecti n g e rro rs T ra n sla ti on p ro cess
S yn tax e rro rs L exi cal a na l ysi s (sca nn i n g)
L og i c e rrors S yn tacti c a n al ysi s (p arsi ng )
P ee r ch e ck T yp e ch e cki n g
Desk ch e cki n g Cod e g e ne ra ti o n
Use o f e xpe cte d ou tpu t T he l in ke r
Run -tim e e rrors T he l oa d er
Deb u gg i ng too l s T he op ti mi se r
B re a kpo i nts A dv. Di sa dv of com p il e r,
Rese tti n g va ria b l e con te nts i nte rpre ter, i ncre me n ta l co m pi l e r
P ro g ram tra ces
S in g l e l i ne step p in g


Concept: Implementation: Design of Individual Concept: Implementation: Major aspects for the Concept: Implementation: Some elements used to
Screens user interface: support user interaction
Definition: a good program can be considered use- § consistency: similar operations should be achieved § buttons: click, double click
less if the interface design is poor. Some factors: the same way § switches: alters screen structures eg. background
§ type of data to be presented: input or output § familiarity: use words that users can understand § menus: pull down
§ type of audience eg. age, teenagers, business § forgiveness: allow users to recover from errors § indicators: activated to show action is occurring
§ assistance required by the user: degree of Help without a major crashes eg. percentage indicator bar for installation
§ consistency between screens § robustness: should handle unusual procedures § displays: show data
§ type of application: graphics, Maths drill without crashing § sliders: moved to alter views or scales
§ degree of interaction by user: game, database § feedback: should communicate with the user when § colour: use and misuse
§ number of screen elements to be included necessary § greyed colours to show active/inactive windows
§ appropriate messages are critical to prevent users § guidance: should provide some form of Help § use red for error messages
taking destructive action. eg. Are you sure you wish
to Delete this file?

Concept: Implementation: Identification of data Concept: Implementation: Popular approaches to Concept: Implementation: Design of Help screens Pt1
required. producing screen designs Definition: encourage the user to seek assistance
Definition: The way in which data is displayed can § simple graphics programs to produce GUI immediately when a problem is encountered. Two
help the user relate to the process being carried out. § programming languages VB6, Delphi produce kinds: Help, I have a problem; Help I need some
their own screens information.
Summary Points: News Article: Y/N § DBMS have their own screen design facility. eg: § partial or full help screens: dependent on case
§ sequential: one screen follows another Access [database management system] Factors of Help screen design:
§ event-driven: user input decides order of the § File -> Save; located in upper left corner of screen § non-instrusiveness: operates only when requested
screen display. since everyone is used to it being there. User will § flexible sizing: move & resize to see underneath
§ text can be: menus, labels, arrays & records make fewer errors learning the new software § consistency: appears in the same area of the
§ graphics can be: background pictures, graphical § use colour to select menu item screen each time it is called.
icons, menus § use common Short-cut keys eg. Ctrl-S to save § navigation: user can easily move around the Help
§ Once data format identified, it is easier to decide § scrolling menus for large menus menu using browser buttons, tabs or hyperlinks
on the programming approach to be used. § Everyone one insists on a GUI interface § simplicity: provides basic explanation with links to
§ text-based interfaces (command interfaces) are more detailed explanation
Example: library program which displays the results on the decrease. § contextual: help is adjusted to the task currently
of a search. Data elements of the screen include being carried out by the user.
search criteria, a list of matches & a means of getting § style: always positive & provides actions rather
more details about each of the matches than general statements.


Concept: Implementation: Design of Help screens Pt2 Concept: Implementation: Audience identification Concept: Implementation: Consistency in Approach
Different types of Help screens:
§ context: small assistants that become available Definition: the intended audience for the program eg Definition: consistency allows users to anticipate
within the application to help with a specific problem teenage game, business application. Range of ex- actions placement eg. printer menu
at a particular moment. Ability to turn it off. perience.
§ browser: provides a large range of Help strategies, Summary Points: News Article: Y/N Summary Points: News Article: Y/N
has a Find function. eg. context, index, find § age: huge difference of approach for different § consistency should occur on each of the screens
§ procedural: takes the user sequentially through age groups Current Traditional approach:
the steps needed to carry out a process § level of expertise: inexperienced users require § folders & directories: storage on hard disk
§ tutorials: teaching help screens that show the more assistance but should be able to turn help off § Save command: shown as a disk icon
user how to use an application in relative detail. by expert users. § Printer icon for print commands
§ error messages: should identify the problem in a § language level: technical terms to be avoided. § letter B used short-cut key for bold format
non-embarrassing way (no beeps or HONKS) § level of specialization: geographical mapping pro- § consistent location of feedback messages
§ beware of overwhelming user with too much Help gram can use a technical interface as compared to a § consistent placement of screen elements
simple spreadsheet. § consistent background & colours
§ the more general the program, the more help will § consistent use of font or typeface
be needed

Concept: Implementation: Language Syntax Concept: Implementation: Role of the CPU in the Concept: Implementation: Role of CPU continued
English is a vague language & often phrases have operation of software. § fetch execute cycle
more than 1 meaning. Computing languages can’t use Definition: CPU is the heart & brain of a computer Subprograms come from:
phrases that have more than 1 meaning. system § subprogram specific to main program
§ ALU: arithmetic logical unit: carries out arithmetic § library: eg calculation of square root
Metalanguages were created to describe the rules of a and compares numbers <,> or strings § subprograms that are part of operating system
programming languages so phrases can’t mean more § control unit: coordinates the actions of processor § linker: subprogram’s address in incorporated into
than 1 thing. Metalanguages are used to represent § register: memory location within the CPU the program by this translation system
the syntax of programming languages. We deal with 2 § direct addressing: addresses a memory location § DLL: dynamic link library: library can be updated
types: § accumulator: working register, holds data items with a new one. eg. dll’s in Windows.
that are being currently processed § Instruction format: conveys a number of pieces of
§ EBNF & BNF with repetition structures: text based § special-purpose: store flags (boolean), to indicate information to the processor. Instruction byte 1,
§ railroad diagrams: graphics based whether a processed instruction results in true/false instruction byte 2, instruction byte 3.
§ program counter: stores the memory location of § source code (3rd level language) is translated to
Both methods carry out the same task but one is text the next instruction (register) assembly code (2nd generation language)
based (like Help in QBasic) and the other is graphics § stack pointer: keep track of the location of the
based. beginning of the stack (part of main memory)
§ stack: Last In First Out LIFO; stack of plates
See more on metalanguages elsewhere in the § clock speed: speed of CPU. 1GHZ = 1000 million
summary sheets. electrical impulses per second

Concept: Implementation: Translation methods in Concept: Implementation: Translation continued: Concept: Implementation: Translation continued:
software solutions lexical analysis[scanning]: spaces, indentations, § code generation: traversing the tree, converts
Definition: instructions must be converted from hu- comment, removed, assigned a token. tokens to object code when enough tokens have been
man readable form to machine-readable form. § token represents key word of language or collected.
(source code to object code) § identifiers created by programmer eg. SIDE_A § linker: links code to calls to the operating system,
§ compilation: all of the code is translated at once. identifier tokens stored in a symbol table so translator to other subprograms and to libraries.
Will be executed more quickly than interpreted can keep track of them § loader: adjusts memory location references so they
§ interpretation: translated line by line Syntactic analysis[parsing]: arranges the tokens in a do not interfere with other parts of the program.
§ incremental compilation: commonly executed way that allows the computer to understand the logic Memory locations may vary each time the program is
routines are compiled while the program itself is trans- § parse tree: hierarchical structure. Only one mean- executed.
lated by interpreter. Speeds up interpreted side. ing allowed per instruction § optimiser: reduces the amount of code so it oc-
§ translation process: language translator is itself a § error produces a ‘syntax error’ because token can- cupies less memory and to organize the code so that
computer program. not be placed on the parse tree. it runs faster
Process of translation: Type checking: detects data types of tokens and
detects incompatible operations between differing
source[characters]->lexical analysis[tokens]-> data types and creating error messages. eg. adding
syntactic analysis & type checking[statement blocks]-> a string to a number.
code generation[machine code]->object code

Concept: Implementation: Translation continued: Concept: Implementation: Program Development Concept: Implementation: Program Development
Advantages & Disadvantages of each method: Techniques: Structured Approach complex solution Techniques: stubs
compiler adv: will run faster than interpreted. Hides Definition: a hierarchical method involving dividing Definition: are dummy modules to substitute for
code from view & one can’t see algorithms used. a complex program into modules. Meaningful names those sections of the programs that have yet to be
Smaller than the high-level code that generated it. & comments identifies the tasks of each module while written.
compiler disadv: run time errors not apparent. Modi- meaningful variable names identify the purpose of § allows one to see if main logic is correct
fications means entire program has to be re-compiled, each variable. § is always simpler than the subroutine it represents
makes testing tedious. § allows the main program to be debugged & tested
interpreter adv: during testing errors become apparent One Logical task per subroutine: self-contained sub- before modules are added
errors can corrected as found. Allows for quick removal routines each carrying out a separate task.
of debugging aids. § easily tested before joining to main program Flags: Boolean variables used to record whether cer-
interpreter disadv: runs far more slowly. Code is eas- § isolated & reused as a library routine elsewhere tain events have taken place in a program.
ily accessible to anyone else. Takes up more storage. § replaced when the task needs to be altered or § decisions can be made on the state of the flag
incremental compiler: will run faster than those of an updated § useful for the testing phases
interpreter but retains the advantage of identifying § easily understood by maintenance programmer § value is normally set to ‘false’ initially
errors as they are reached. § if error occurs, easy to identify module Example of flag:
incremental compiler disadv: not executed as quickly § adaptability to a team approach for development IF Paid=”” THEN
as compiled program. Code is accessible to others Flag=True
which could be illegally used. ENDIF


Concept: Implementation: Program Development Concept: Implementation: Program Development Concept: Implementation: Program Development
Techniques: Isolation of Errors Techniques: Elegance of solution Techniques: Detecting & correcting errors
Definition: a method of detecting errors. Definition: elegant solutions are simpler algorithms Definition: a developer need to develop the patience
& therefore easier to understand, and due to simplicity & skill necessary to detect & correct errors within a
§ Tracing the flow of the program will form smaller & faster code. program.
§ Step through the program manually syntax error: errors that have broken the syntax rules
§ debugging tools: breakpoint, watch for variables Writing for subsequent maintenance: all worthwhile of the programming language. Could be typing mis-
§ once error found, could mean the changing of a code will need maintenance in the future. To make takes, incorrect punctuation & spelling mistakes.
condition or the complete rewrite of a module. maintenance easier the program should use modular- § failure to complete grouping such as REPEAT with
isation, good internal documentation & process an UNTIL; IF ELSE ENDIF
Debugging output statements: temporary statements documentation that covers all aspects of program § today’s compilers / interpreters attempt to give
placed within code to assist with the process of debug- design & testing. a clue as to the identification of the error eg. datatype
ging such as identifying variables or seeing if a mismatch.
module has in fact been activated. § use of a reserved word
eg “Processing the file has been started” or logic errors: errors in the design or the code imple-
“The stimulus name is animated.avi” mentation of a program that result in incorrect output.
§ desk checking, peer checking, breakpoints, use of
§ debugging statements are removed. debugging output statements aid in detection of errors

Concept: Implementation: Program Development Concept: Implementation: Program Development Concept: Implementation: Program Development
Detecting & correcting errors continued: Detecting & correcting errors continued: Use of software debugging tools
Peer checking: is having somebody of comparable Breakpoints: are places where the program is made to
standard to the programmer check the code or algor- run-time errors: errors that are not detected until a stop during execution. This allows the programmer to
ithm for errors in logic. program is running. examine the contents of memory locations, variables.
§ caused by inability of the computer to perform the
Desk checking: where an algorithm is manually intended task. eg. division by zero resetting variable contents: placing statements within
worked through with test data items. The results are § control not following the paths as designed the code that change the values of those variables to
tabulated on paper and compared with actual outputs. § program trying to access inappropriate memory known values. The effect of processing can be seen
locations. eg. accessing an array location that doesn’t and verifies that the variables are processed correctly.
Use of expected output: A test data table is designed exist.
to show the expected output from using a range of § run on different operating systems program traces: one follows the order of execution of
data input. The expected output is compared to the a program by displaying each line as it is executed.
actual output. If variation occurs, then a check for The actual flow of execution is compared with the
errors has to take place. expected flow from the source code.

single-line stepping: following the value of variables
line by line as the program is executed. A subroutine
can be executed as a whole or stepped through as
well.

Concept: Implementation: Documentation of a Concept: Implementation: Documentation of a Concept: Implementation: Documentation of a
software solution: software solution: User documentation: software solution: User documentation: continued:
Overview: documentation forms an integral part of functional description: brief outline of the system system reference manual: has a complete listing of all
each stage of the system development cycle. requirements & purpose of the system the functions of the program.
§ process documentation: value to the developer or § has a listing of known operational errors & how to
maintainer installation guide: specifies minimum hardware & recover from them
§ product documentation: value to the user operating system requirements. Written in a non- § each function described in detail, inputs / outputs,
technical manner. May be users first contact with the and any special features.
process diary: a log kept by the programmer of all the program. Illustrations should be used. § written in a more formal style & will tend to be
steps taken in the development process. It is updated more technical.
regularly. introductory manual: describes the common functions
§ allows a new member to become quickly familiar of the program. system administrator’s manual: designed to provide
with the process § should include tutorial on how to carry out the the system administrator with a comprehensive des-
§ documents the milestone & pitfalls common functions & how to recover from common cription of the program & how it interacts with other
§ allow maintenance programmers to understand errors. elements eg. how to run from a network and known
the processes that were originally undertaken. difficulties.

Concept: Implementation: Documentation of a Concept: Implementation: Documentation of a Concept: Implementation: Hardware environment to
software solution: User documentation: continued: software solution: Self-documentation of the code enable implementation of the software solution.
§ use of intrinsic naming within coding hardware requirements: degree of power needed by
user manual: is the main reference by a user § use of intrinsic characters to break up the coding computer system. eg. multimedia system requires
§ clearly & logically set out with full index into segments which is pleasing the human brain more power than just word processing.
§ description of each function and examples § use comments to explain sophisticated chunks of § platform: specific operating/network system
§ methods of navigation code § configuration: processor, clock speed & RAM
§ written in a concise, clear, non-threatening § memory: amount of primary/secondary storage
manner technical documentation includes: required to install program.
§ could be a form of online Help § source code § peripherals: additional hardware outside the CPU
§ should contain a series of tutorials § algorithms eg. printers, OCRs, scanner, CD-RW
§ trouble shooting guide § data dictionary § communications: networks & internet systems that
§ use of Balloon text within a GUI eg. cursor over § systems documentation link two or more computers together.
icon produces a text that labels the icon The above technical documentation provides the back-
bone for future maintenance programmers. minimum configuration: minimum hardware require-
§ various general applications can be used to prod- ments needed to run the software efficiently.
uce documentation. § developer should always specify a level of memory
§ templates should be used to promote consistency § processor speed, specific input/output devices
between documents § minimum operating system

Concept: Implementation: Hardware environment to Concept: Implementation: Emerging technologies Concept: Implementation: Emerging technologies
enable implementation of the software continued: Definition: developments in hardware/software can continued:
possible additional hardware: specialised peripherals have an effect on the development process.
may be needed eg. bar code scanner, optical character software:
recognition. hardware: § improvements in operating systems & utilities,
§ has continuously moved to smaller parts, faster more intuitive eg. Norton’s utilities -> communications
appropriate drivers or extensions: drivers are small processing & bigger memories § compatibility problems with existing software eg.
programs required to run tasks carried out by a per- § digital devices are replacing analogue equipment Mac OS 10 won’t run OS 9 products
ipherals. Extensions are files that usually are with the § artificial intelligence is emerging § programming environments should improve
operating system & assist in the execution of some § data gloves with electronic sensors § software isn’t as efficient as it used to be due to
programs. § voice recognition added functionality & more powerful computers
§ drivers, extensions may need to be part of the § natural language reproduction § backward compatibility
installation process but as an option. § DVD’s, CD-RW, thumb drives are changing how we
§ eg. older operating systems may not have net- store files
working capability

Concept: Implementation: The effects: Concept:
of emerging technologies:
§ made available to the greatest number of people Definition:
and to the greatest benefit

on the human environment: individual perspective Summary Points: News Article: Y/N
through a global one § Bibliography:
§ a better standard of living Fowler’s HSC SDD text
§ new forms on entertainment & information Wilson’s HSC SDD text
§ ability to perform tasks that were previousl §
impossible please turn page.
§ change of employment (redundancy)
§ impacts will vary from economic effects through §
to environmental effects, local, national & global

on the development process: almost mandatory to Example:
provide online assistance rather than manuals. Printed
manuals are being distributed in electronic form
rather than on paper.


Symbol Meaning BNF & EBNF Examples Example: in BNF
<language element> Language element defined somewhere else <digit> Digit:: = 1|2|3
(called non-terminal symbols) These may be <letter> Number:: = <digit> * <digit>
§ pre-defined – given names
§ individual characters Number=1*2,Number=1*3 are legal.
Number=3*4 is illegal because it is not a predefined
Language element Terminal symbols-each character in a string of display digit or 1 or 2 or 3.
characters is a terminal symbol
Example in EBNF
Alternative|Alternative he vertical bar is placed between alterna- A|B|C meaning A or B or C Digit = 1|2|3
tives. There may be 2 or more of theses. Number = <digit> * <digit>
Sum={<Number>}-{<Number>}
::= Represents ‘is defined as’ Word::=<letter><letter><letter>
meaning Word is defined as 3 letters Legal: Sum=(1*2)-(2*3) & Sum=(1*2)(2*2)-(2*3)
Illegal: Sum=(1*4)-(2*3) because 4 is not defined.
= Represents ‘is defined as’ Letter=A|B|C|D|E
Letter is defined as A or B or C or D or Number is defined as 1or2or3 followed by * and
E another digit. Sum is defined as a repetition number
which could occur once or many time.
{} Repeated elements enclosed in braces. The Word={<letter>} Concept:
loop may NOT be carried out. Word is defined as a repetition of the
predefined element letter

[] Optional elements in square brackets String=<letter>[+]<letter>
String is defined as a letter element,
an optional + meaning it may be used
or may not be used and another letter
element

() Grouped elements in parentheses ({<letter>}) The repeated letters are
part of the one group.


Concept:

Concept:


Diagrams from Wilson’s SDD HSC text.

SDD HSC Testing & Evaluation Page 28 of 43

Whi te b o x te sti n g
.
S ta te me nt co ve rag e te sti ng
E nsu re sp ecs. h a ve me a sura bl e Deci sio n -co n di ti o n cove rag e
CAS E to ol s: o uto cme s te sti n g
T est da ta g e ne ra to r Cla ri fy va gu e te rms M ul ti pl e de ci si o n -co nd i ti on
A n o racl e Cla ri fy a mb i g uo u s state me n ts cove rag e te stin g
Fi le com pa ra to rs Cal cu la ti on s accom p an i ed b y E xh a usti ve con d i ti o n d e ci si o n-
T est ma n ag e me nt to ol s e xa m pl e s con d i ti o n co vera ge .
Dia g ram Pi cture s u se d to cl a ri fy B la ck b o x te sti n g
stru cture M od u le testi ng :
S oftware te st de scri p tio n B ou n da ry a n al ysi s
A ri th me ti c e rrors
S oftware de scri p tio n te st pl a n E qu i val e nce pa rtiti o ni n g
Com pa ri son erro rs
S oftware de scri p tio n te st re p ort Con trol l og i c erro rs
B la ck b o x te sti n g Data stru ctu re e rrors
Com pa ri son of th e so lu ti on a nd ori g i na l Whi te b o x te sti n g In pu t, O u tp u t e rrors
Docu me n ta ti on o f te st d ata & o u tp u t d esi g n sp eci fica ti on s. In te rface erro rs
p rod u ce d . G en e ra ti ng rel e van t te st da ta fo r
Use o f CAS E to o l s com p le x so l u ti o n s.
Com mu n ica ti on wi th cl i e nt / use rs L eve l s o f te stin g
T est resu l ts P ro g ram :
Uni t or m od u le testi n g
Com pa ri son wi th ori g in a l sp e ci fi ca ti on s. In te g rati o n te sti n g
P ro g ram
T op -do wn a p pro ach Dri ver
S yste m S yste m: m od u le
Use o f l i ve te st d ata to te st com p le te P erfo rm a nce te stin g B otto m-u p a pp ro ach
sol u ti on Reco ve ry te stin g Fun ctio n te sti ng
T esti ng S oftwa re L arg e r fi l e si zes S ecu rity testi ng
Rep o rti n g o n th e A cce pta n ce testi ng , al p h a o r b e ta
S ol u tio n M ix o f tra nsa cti o n type s S tre ss te sti n g
T esti ng P ro cess te sti n g.
Resp on se ti m es
S DC: Te sti n g V ol u me da ta
T est resu l ts: & E val u a ti o n In te rface s b e twe en mo d ul e s Q ua l i ty A ssu ran ce2 :
P ro b l em s m a y ca use d e l ays. Com pa ri son wi th pro gra m te st d a ta Q ua l i ty A ssu ran ce1 : m od i fia b i li ty
E ffi ci en t use of reso u rce s? B en chm a rki n g Cla ri ty m od u la ri ty
M an a ge me n t d e ci si o n. Q ua l i ty a ssu ran ce. corre ctn e ss p orta bi l i ty
d ocu me n ta ti on re li a b il i ty
e co n om y re si l e nce
e ffi ci en cy re usa bi l i ty

System Development Cycle: fl exi b il i ty
g en e ral i ty
te sta bi l i ty
u nd e rsta nd a bi l i ty
i n te g rity
Testing & Evaluation
u se a bi l i ty
i n te ro pe rab i l i ty val i d i ty
m ai n tai n ab i l i ty


Concept: Testing & Evaluation: Concept: Testing & Evaluation:
Compare solution to original design specs. Generating relevant test data for complex solutions

§ Compare end product to the original design § Can’t test for every possible aspect in complex
specifications. Solutions.

§ Good quality, operate reliably, maintenance is § Wide range of testing procedures are used.
possible.

§ Interface, input output, procedures meet specs. § Whitebox testing
Black box testing

Example: Compare Quiz end product to design Example:
specifications as given by the client (teacher). § XP Operating system
§ Vista Operating system

Concept: Testing & Evaluation: Levels of testing Concept: Testing & Evaluation: Concept: Testing & Evaluation: Program testing
Unit or Module testing
Definition: Progressive testing, starts at lowest level Definition: Each module is tested to make sure it Definition: ensures that the modules work together
(module), moves to program level and then tests the works as a unit and is free from error. and the mainline of the program performs correctly.
environment (system) in which it will operate Parameter passing. Module to Main program relations
§ module testing has mostly taken place in § Each module should perform a separate task. § integration testing: combining the modules
implementation stage § Each module is treated as a stand alone appli- § top down: main -> related modules to main
ation. Test for: § bottom up: test lower level modules first which
§ both black-and-white box testing is used. § arithmetic errors incorrect calculations in turn make up larger modules.
comparison errors: different data types AND § function testing: Users test product & compare
instead of OR against specifications of the user
§ § Control structure errors due to boundaries, incor- § acceptance testing (custom built): tested where it
rect initialization, or termination will be used
• data structure errors: flags, counters § alpha, beta (commercial): first phase under con-
Example: • input, output errors: reading writing to files trolled conditions, 2nd phase more open after bugs
• interface error: parameters passed correctly from corrected from alpha phase.
one module to another


Concept: Testing & Evaluation: System testing Concept: Testing & Evaluation: Live test data Concept: Testing & Evaluation: Live test data
continued
Definition: checking the program in environments Definition: The real data the program will work with. § comparison with program test data: previous test
outside the development environment. data is compared with live data to make sure actual
output matches the expected output.
Summary Points: News Article: Y/N Summary Points: News Article: Y/N § Benchmarking: comparing a program against
§ ensure that hard/software, data, personnel and § larger file sizes: difficult to simulate very large files a set of established standards. An objective process
procedures work together efficiently, correctly and as hence, we use real data. but results can be interpreted. Usually compare the
intended. Tests focus on: § Mix of transaction types: real operations encounter old system with the new system.
§ performance testing: quality of the performance by more mixtures of transaction types, some not antici-
increasing the transaction load until it fails. pated.
§ recovery testing: measures the ability to recover § response times: times required to complete
itself or the average time for humans to recover it. responses. Limited test data may not give accurate
§ security testing: attempts to breach security of the response times.
system. Includes computer & manual procedures. § volume data: amount of data to be processed. One
§ stress testing: create situations where the sysem would use pre-existing data.
may fail such as rapid reading, writing to disk. § interfaces between modules: meeting point be-
§ some tests may overlap with each other module & main program. Link may be direct or by
communication link. Response time may vary.

Concept: Testing & Evaluation: Quality Assurance Concept: Quality Assurance continued: Concept: Testing & Evaluation: White box testing
§ maintainability: ease in which an error in the also known as Structural testing
Definition: assures customers of the quality of a prod software can be corrected. Definition: identify and to correct problems emerg-
uct. Must be built into it, can’t be added to an existing § modifiability: ease with which the software can be ing during the product’s development.
product. changed to meet new needs or circumstances. § statement coverage: each statement is executed
§ clarity: precise & unambiguous instructions § modularity: able to replace one part without re- in a module.
§ correctness: consistent correct output placing the entire product. § decision condition: test data is used to test each
§ documentation: consistent high standard docum. § portability: ability to work in different hardware & branch within a decision structure within a module
§ economy: economical in use of processing needs software combinations. § multiple decision-condition: tests all possible com-
and external resources. § reliability: a measure of the failure rate of software binations of multiple decisions. Nest selections, case
§ efficiency: efficient production of output § resilence: ability to recover from an abnormal § exhaustive condition decision-condition:
§ flexibility: ability to cope with all situations during situation. tests all combinations of true false for each condition
processing. § reusability: components can be used in future
§ generality: eg. word processor interface setup to tasks.
look like typing on a sheet of paper. § testability: how easily the software can be tested
§ integrity: withstand attacks on its security § understandability: quality technical documentation Example:
intentional or not. allows the software to be understood.
§ interoperability: ability to communicate with pre- § useability: time for the user required to learn it.
existing software eg. operating system § validity: meets the specifications of user


Concept: Testing & Evaluation: Black box testing Concept: Testing & Evaluation: Documentation of the Concept: Testing & Evaluation: Use of CASE tools
also known as Functional Testing test data & output produced.
Definition: identifies that a problem exits within a Definition: Testing needs to be a carefully controlled Definition: Specific CASE tools have been created for
module. Does NOT identify the source of the problem and executed process to provide maximum information the testing process.
about the software.
§ boundary analysis: choosing test data that are § software test description: describes the prepara- § test data generator: develops test data items ac-
representative of both sides of a boundary. tions for the tests. cording to a set of rules.
§ oracle: predict the output of a program
§ equivalence partitioning: involves breaking up § software test plan: describes the test environ- § file comparisons: analyses the results between 2
the data input into groups that have the same prop- ment, the tests to be performed & provides a time sets of data,usually from the old system & new system
erties. eg. database field entitled Family Name. frame. § test management: handles testing processes for
legal characters & illegal characters determined and § software test report: provides information about multiple tests.
processed / tested. the conduct of the tests & the results. § volume tester: simulate use by multiple users.
§ functional tester: simulate user interaction
Example: Example: § simulator: various kinds (machine simulation)
§ WinRunner, LoadRunner, DataTech [CASE titles]

Concept: Testing & Evaluation: Communication with Concept: Testing & Evaluation: Test Results Concept: Testing & Evaluation: Comparison with
the client the original design
Definition: Custom software, the client more involved Definition: problems identified in the testing process. Definition: Each specification to be checked. If all
as compared to off the shelf. Results need to be frank working then all Ok. If not, needs to be brought up
direct & non-technical language. to standard and an explanation of the shortcomings.
§ § bugs, inconsistencies, lengthy response times or § efficient use of resources?
hardware conflicts.
§ problems may cause delays.
§ § limitations of the program may be issues § management decision to wait for full product.
§ response to live data & coverage of all the test
results that show the program meeting user needs.
§ § may include recommendations related to future §
development: bug fixes, rewrites of modules or ex-
panding the application.


Concept: Concept: Concept:


§ § §

§ § §

§ § §




§ § §

§ § §

§ § §


SDD HSC Maintenance Page 33 of 43

M od i fy:
Rem ove a b u g (p atch).
Cha n ge s in i np u t d a ta.
Cha n ge op e rati o n.
M ee t ne w re qu i rem e nts.
Imp ro ve effi cie n cy.
Hard /so ftwa re ch an g es
G ovt re q ui re me n ts
Curre ncy of P ro d uct
M ai n ten a nce typ es: Imp ro ve d fu n cti o na l i ty
Corre cti ve M ai n ten a nce
A da p ti ve Ma i nte na n ce
Imp ro ve me n t M a in te na n ce

Cha n gi n g u ser re qu i rem en ts
Upg rad i n g u ser i nte rface
Cha n ge s in d ata to b e p roce sse d
Cha n ge d m e th o ds o f d a ta p roce ssi n g
In tro . of n ew ha rdwa re / softwa re
O rg a ni sa tio n Cha n gi n g o f org an i sati o na l focu s Con fi gu rati o n m an a ge m en t:
T ech ni ca l Cha n ge s in g ov't re q ui re me n ts M an a ge me n t o f ve rsi on s & rel e a se s
P oo rl y i m pl e me n te d co d e o f so ftwa re.
Id en ti fi ca ti o n o f the rea son s fo r cha n ge S yste m b ui l d in g
Nee d s L oca tio n of secti on to b e a l tere d Con trol & m a na g em en t of syste m
Use r Dete rmi n in g ch a ng e s to be ma d e cha n ge
L eg i sla ti on Imp l e me nti n g & te sti ng a so l uti o n Con fi gu rati o n p l an n i ng

System Development Cycle: M od i fica tio n of Cod e Con fi gu rati o n m an a ge m en t
S ou rce cod e , m a cro & scri p t
d ue to Cha n ge d
Maintenance Req u ire me n ts d ocu me n ta ti on
M od i fica tio n of a sso cia te d h ard co p y
d ocu me n ta ti on & o n l in e he l p
Docu me n ta ti on o f Use o f CAS E to o l s to m o ni to r ch an g es &
Cha n ge s versi o ns
S DC: Ma i nte na n ce
o f S o ftwa re
S ol u tio n s


Concept: Maintenance: Changing user requirements Concept: Maintenance: Upgrading user Interface Concept: Maintenance: Changes in the data to be
Maintenance: upgrading or repair of a program. processed
Definition: User becomes more familiar with the Definition: user interface often contains aspects that Definition: Changes in the form of the data to be
application & needs to perform further tasks. Their would benefit from redesign. Long term use may processed.
needs evolve & grow. bring to light problems
Summary Points: Summary Points: News Article: Y/N Summary Points: News Article: Y/N
§ Maintenance costs are over half of the total § § Millennium bug:
system development cycle.

§ Much is needed from software today and more § § Australian telephone numbers increased to 8 digits
will be required tomorrow. Software needs to be able § ABN number required on all invoices within Austr.
to be upgraded with as little disruption as possible to
the user. §
§ Banks had to modify their software to utilize tax
file numbers when introduced by legislation.
Example: Example: design of menu & key combinations used Example:
for shortcuts.

Concept: Maintenance: Introduction of new hard- Concept: Maintenance: Changing of organisational Concept: Maintenance: Changes in government
ware/software focus. requirements
Definition: Definition: a business continually goes through a Definition: legislation changes which in turn reflects
process of evolution social, political & economic circumstances.

§ Long last software has to undergo modification to § often business expansion is similar to the core § ABN number
make use of new technology and to take advantage of business and the software can be adapted to the new
what the new technology has to offer. acquisitions.
§ § § tax file number

§ § § display costs of ATM transaction
§ track use of particular chemicals

Example: Introduction of laser printers, scanners & Example: P&O evolved from just a shipping company Example: chemists have to enter who purchases
new operating systems. to running cruise liners, owning resorts, cleaning certain tablets eg. sudafed
* USB Ports company.


Concept: Maintenance: Poorly implemented code Concept: Maintenance: Identification of the reasons Concept: Maintenance: Reasons for changing code
for change in code, macros & scripts § bug fixes (patch)
Definition: Older software may not be as structured Definition: Maintenance is not about a quick fix but § changes in input data (6 to 8 digits)
as it should be, hence, reducing efficiency. Mainten- about creating a lasting solution. § change in operation
ance of code is preferred over a patch. § identify the needs of the user § meet new requirements: changes to govt regu-
Summary Points: News Article: Y/N § identify the needs of management / govt lations or organisational structure. eg. GST
§ § full documentation on the problem, solution § improve efficiency
is needed, particularly when more than likely a dif- § hard/software changes eg: printing to a laser
ferent programmer will carry out the maintenance. § govt regulations
§ § as time passes, technology becomes outdated § currency of product: bring code up to date. eg.
§ technical needs move from assembly language to event-driven
§ legislative needs language
§ § user needs § improved functionality: expand the original solu-
§ organisational needs tion. eg. add module for greater choice of fonts.

Example: Usual Problem-solving strategy:
define the problem->design a solution->test and
implement the solution

Concept: Maintenance: Location of section to be Concept: Maintenance: Determining changes to be Concept: Maintenance: Implementing & testing
altered made a solution
Definition: where alterations to coding will take place Definition: The cost & impact of changes have to be Definition: testing of changes should be just as
assessed. rigorous as full implementation of original program
§ priority: urgent if business can’t operate
Summary Points: News Article: Y/N § extent: number of changes to be made and level Summary Points: News Article: Y/N
§ can be new modules: easier to do because no of difficulty eg: screen design adjustment vs adding § changes probably need to be carried out in the
pre-existing structures have to be linked eg. parameter a new function same environment as originally created eg TUSIL
passing § personnel: who does the changes, in-house or will
§ modification of existing code requires understand- it be outsourced? § use test data for revised specifications
ing of specific module and impacts upon other § skills & expertise: the skills needed to make the § minimise downtime
modules. changes at time of maintenance.
§ thorough understanding of original code and § changes could have impact on other parts of the § may involve retraining of users
thorough understanding of original documentation program
is usually needed.
Example: Example:

Concept: Maintenance: Configuration management Concept: Maintenance: Source code, macro & script Concept: Maintenance: Modification of associated
documentation hard copy documentation & online help
Definition: management of software resources. Definition: should follow the rules covered earlier Definition: any changes in software has to be re-
configuration planning, control & management of in the course eg. intrinsic documentation flected in documentation that goes with the product.
system change, system building, management of
versions & releases of software. Summary Points: News Article: Y/N Summary Points: News Article: Y/N
§ configuration planning is where documents needed § code: high-level language § updating & distributing hard copy documentation
for further development are identified & placed under is quite cumbersome when compared to online help
configuration control.
§ when software is modified so must be the respect- § macros: prerecorded automated tasks § online documents can be easily downloaded from
ive documents. the Internet or from a CD
§ change control: software changes are done in a
controlled & predictable way § script: commands carried out without user inter- §
§ modification to original code needs to be docu- action eg. JavaScript
mented. § descriptions of the process & design document-
Example: ation assists in the maintenance process. Example:
§ Word tracks changes in a document

Concept: Maintenance: Use of CASE tools to monitor Concept: Maintenance: Concept: Maintenance:
changes & versions

§ a number of configuration management tools exist. § §

§ Merant’s PVCS is one specific title § §

§ § §


SDD HSC OPTION: Evolution Programming Languages Page 37 of 43

M eth od s:
M essag e : Defi n es wha t th e ob j ect ca n do . eg . ca r Fi rst Ge n era ti on (ma ch i n e) l an g ua g e:
P are am e te rs, tu rn s ri g h t o r le ft. 5 th G en e ra ti on L an g ua g e: Cod e d i n b i n ary di g i ts.
Evolution of O pe rati o n,
Desti na ti on
A n o bj e ct e n ca p sul a tes the pro p erti es
& th e a l g ori thm s th a t a re u se d to
Use s arti fi ci a l i n tel l i g en ce m eth od s for p ro b l em
sol vi n g.
Hexi d eci ma l , o ctal d eve l op e d to re d uce
e rro rs i n cod i ng .

Programming p roce ss the m vi a me ssa g es. Use s l og i c p rog ra mm in g ... b ase d o n th e pri n ci p l es
o f fo rma l lo g i c.
M ne mo n i cs.
P ro ce sso r-d e pe n de n t.
P RO LO G : re sol u tio n -> d ed u cti o n Can resi d e o nl y i n 1 lo ca ti o n wh ich
Languages A bstracti on :
A p ro bl e m ca n b e vi ewe d i n fa m il i a r
Cla sses:
A sp e ci a l a b stra ct d a ta type .
cau se d 2 nd g en e ra ti on

te rm s e g . o b j ects.
Option
Refe rs to th e pro pe rti es o f th at d ata 4 th G en e ra ti on l an g ua g e:
A ll o ws u s to sim p li fy th e pro gra mm i ng i tem . WHA T th e p rog ra m h as to d o ra the r th a n
p roce ss. P are nt -> Cl a ss -> su bcl a ss HOW it i s to be d on e . 2 nd -Ge n era ti on sym bo i c l a n gu a ge :
Data Ab stra ctio n : l o o ks a t d a ta i n Com pu te r p o we r in crea sed , co st de cre a sed . Use s sym bo l i c a d dre sse s.
fa mi l i ar term s su ch a s ch ara cte rs & A tte mp ts to ma ke i n tera cti o n wi th h u ma ns Cha racte risti cs A sse mb l e r ta ke s ca re o f ne w me mo ry
n um b ers. In he ri ta n ce : e asi e r. l o ca ti on .
P ro ce ss a bstracti on : seq u en ce o f In a h ei ra rch i al stru cture is th e a bi l i ty Cha racte rise d b y si m il a ri ty to sp ee ch e g . Note s i n co d i ng al l o we d .
i n stru cti o ns tha t ha ve a cle a rly o f th e cl i en t to h ave al l the L og o , Hype rtal k. M ay i ncl ud e a d eb u gg e r.
Del p hi : d efi n ed a nd l im i ted pu rp ose . cha ra cte risti cs o f th e pa ren t & to ga i n L og o is a ch i l d o f L ISP . A sse mb l y l a n gu a ge ca n ru n fa ster.
Deri ved from Pa sca l . n ew on e s. L ISP si ts on the bo rd er o f 4 th & 5th Deve l op i ng i nte rface s to de vice s,
Deve l op me n t to o l fo r Wi nd o ws A ll o ws u s to re-u se cod e . g en e rati o n l a ng u ag e s. crea ti ng RO M m od u l es, or
with GUI. m icro po rce ssor con trol l e d m ach i ne s ge .
3 rd G en e ra ti on l an g ua g es:
O bj e ct o rie n ted Pa scal . com p act di sc p a l ye r.
G re a t l e a p fo rwa rd.
A n e ven t occurs fro m u se r Not e asy to l ea rn .
In stru cti o ns cl ose r to sym bo l i c
a cti o n. Discri pti o n & O bj e ct O rie n ted La n gu a ge : E vo l u ti o n o f
l a ng u ag e u sed i n sci en ce o r bu sin e ss.
L i bra rie s: cl a sse s of o bj e cts -> Hid to ry o f Con stru cted fro m o b j ects & me ssag e s. P ro g ram mi n g
In de p en d en t of com pu te r syste m .
win d ows, bu tton s, cu sto m to ol s. L an g au g es B la ck b o x: se nd s & re ce i ve s me ssa g es. L an g ua g es
A s te ch n ol o g y i m pro ve d ea ch l i ne cou l d
S im i l ar to V B 6. We h ave no i nte rest i n h ow i t wo rks. b e i n terp rete d.
Can acce ss l oca l & n etwork A n o bj e ct m a y n ot b e u n de rsto o d, b ut can stil l E nca psu l ati o n: FORTRA N: sci e n ce , ma ths
d ata b ase s. b e u sed effe cti ve ly. Fun ctio n al
G ro u p su bp ro gra ms & COB OL : bu si ne ss
O OP are co n ce rn ed wi th o b j ects. re la te d d ata ei th er T ech no l o gy l im i ted co m pi l a ti o n . P ro g ram mi n g
O bj e cts a re resp o nsi bl e for the i r own a ctio n s. i n di vi du a ll y or i n g ro up s of M an u fa cture rs d e ve l op e d th ei r o wn
O bj e cts resp o nd to re qu e sts fro m cl i en ts vi a com p on e nts tha t are re l a te d . versi o ns, he n ce , l im i tin g po rtab i l ity.
C++: m essag e s. S ub p ro g ram s.
A LG OL 6 0 -> C(1 97 2 ) -> C Java : O OP : co di n g (fu ncti o n) & d a ta kep t tog e th e r i n L i bra ry ro uti n es,
v.2(1 98 9 S un Mi crosyste m s 1 9 90 . a n o b je ct. e g. stud e nt m arks p ro gra m. S im p li fyi ng com ms b etwee n P ro g ram wh i ch con si sts e nti rel y of
C++ i s a hyb rid l an g ua g e. O ri g i na l l y fo r sm al l con sum e r A n o bj e ct o n l y n ee d s to be ma n i pu l ate d , we o bj e cts. fu ncti on s.
Fl ag shi p of O OP me tho d ol o gy. e l ectron i c d e vi ce s. d on 't ne e d to se e i n sid e th e ob j ect, he n ce , the S id e effe cts,Re cursi o n.
B ackwa rd co mp a ta i b le with C Nee d ed to b e si mp l e & 'b la ck b o x.' No a ssi g n me nt state me n ts.
Com pi l e d l a ng u ag e -> o bj e ct fi l e e xtre me l y re l ia b l e. Cla ss -> sub cl ass in h eri ts pro pe rti es fro m P ol ymo rp hi sm: No g l ob a l va ria b l es.
L og i c
-> l i n ke d to req u rie d li b rari e s -> P orta bi l i ty. p are n t. For e ffe ctive ma i nte na n ce o r E nsu res n o si de effe cts.
P ara di g m
cove rte d in to e xe cu tab l e . P op u la r wi th we b d e ve l o pe rs & M eth od s: h o w th ey d ea l wi th a me ssag e . e xte n si o n o f a p rog ra m o nl y No l o op s bu t use s re cursi on (a p roce ss
(mo d el )
Com pi l e rs fa ste r tha n a n a l tern ati ve to Mi cro so ft. Re-u se cod e th ro ug h m a ni p ul a ti on an d ad d in g th e a dd i ti on of a su b cl a ss i s o f d e fin i n g i tse l f).
In te rp re te rs Java vi rtu al ma chi n e a l l ows n ew cha racte ri sti cs. re qu i red . G re a tly i mp rove s m o du l ari ty.
Disa d v. i nh e rite d m a ny fau l ts p orta bi l i ty. S ave s ti me , mo n ey & e ffort. V eh i cle -> ca r1 , ca r2 , ca r3, Curre ntl y in e ffi ci en t & n o t su ita b le for
o f C. Disa d v: spe e d, can 't be If an ob j e ct i s d e l ete d, con n ecti on s to th e car4 , ca r5, ca r6 . som e a p pl i ca ti o n s. Ru n mo re sl owl y &
P erce ive d to be too l arg e & com p il e d i n ad van ce b u t a s th e d el e ted o bj e ct h ave to b e re di re cte d co rre ctly. S ub cl ass (ca r) i n he ri ts fo rm n ot sui ta bl e for g en e ra l -pu rp ose
com p le x a l a ng u ag e . p rog ram i s b ei n g e xe cu ted . th e p are n t cl ass, ve h i cl e p rog ram mi n g .
Con trol p ro g ram do e sn 't ha ve Cou l d b e th e wa y o f th e fu tu re .
to b e mo di fi e d.
B ackwa rd Ch ai n i ng :
P ro g ram de si gn e d to a ct l i ke a n exp ert. P ro b l em so l vin g pro ced u re .
K no wle d ge -b ase d syste ms. Heu ri sti cs: Com mo n L IS P:
S ta rts wi th a sta tem e nt & a set
Desi g ne d to de a l wi th u n ce rtai n ty. E xp e rt Cal l e d n on -p ro ce du ral , d ecl ara ti ve or Fi nd i ng a se t o f rul e s th a t P ri n ci pa l la n gu a ge for a rti fi cia l
o f ru l es l ea d i ng to th e state me n t
S yste m l o gi c. fi nd s sa ti sfa ctory so l u ti o n s to i n te l l i ge n ce & 2 n d o l de st g e ne ral -
& th e n works ba ckwa rd,
S he l l s A sso cia te d wi th a rti fi ci a l in te ll i g en ce. a sp e ci fi c p ro bl e m. p urp o se l an g au g e.
m atchi n g ru l es with the
Focu s: a b il i ty to l ea rn, to p ro ce ss E na b le s the cre a ti o n o f ma n y Run i n a n i n tera cti ve e n vi ro nm e nt.
i n fo rma ti on from a d ata b ase o f
kno wl ed g e, to m ake i nfe ren ces & to ga i n d i ffe ren t so l u ti o n s. In te rp re te d l a ng u ag e .
K no wle d ge B ase : fa cts un ti l th e sta te m en t ca n be
kno wl ed g e. P are nt o f L O GO .
Data ba se b u i lt u p b y a kno wl ed g e p rove d e i th e r ri g ht o r wro ng .
S ta te me nts n ot p ro cesse d i n a p reci se
e ng i n ee r. Works b e st o n a sma l l n u mb er
o rde r no r ra p i dl y. G oa l s:
In cl u de s si m pl e facts, ru l es tha t de scri b e o f re sul ts.
Deta i le d sta tem e nts de scri b e wh at i s A ch i e ve d wh en a g ro up of
re la ti on shi p s & p ossi bl e me tho d s. Use r Inte rfa ce: P re m ise : a so urce ca n b e fo un d
true a bo u t a de si re d re su lt. fa cts fro m th e d a tab a se are A PL : a p rog ram mi n g l a n gu a ge .
Data ba se n e ed s to g row as i t l e a rn s ne w P ro vi de s sm o oth & cl ea r co mm u ni ca ti o n with o ut the n ee d to ob ta in a ll th e
In de p en d en ce o f l o g ic & co ntro l . m atche d . (P rove so m eth i ng i s Deve l op e d to co nci sel y exp ress
fa cts. b etwee n th e use r & the syste m. d ata .
L og i c: wh at i s to be sol ved true ). a l go ri th m s i n m a th e ma ti cs whi ch i n
It sh o ul d gi ve i n sig h t a s to h ow the
Con trol : ho w it sh ou l d b e so l ve d . tu rn cou l d b e tra nsl a ted i nto
p rob l em so l vi ng pro cess is carri e d o ut.
Forward Ch a i ni n g: 3 sta tem en ts: fa cts, q ue ri es & ru l es. con ven ti on a l p ro gra mm i ng l an g ua g es.
S ta rts wi th a se t of ru le s & a Use r sup p li e s a g oa l : so l ve d by Can be e xtre me l y d i ffi cu lt to re a d b ut
In fe re nce E n gi n e :
In fe re nce E n gi n e : P ro l o g: d ata b ase o f facts & works to a re so l uti o n o r ba ckwa rd cha i n in g an d / o r see n as i ts stren g th .
P ro ce ssi n g p art o f a n e xpe rt
A pp l i es the kno wle d ge to th e d a ta to a rrive P ro g ram mi n g i n Lo g ic. con cl usi o n b ase d o n fa cts th at fo rwa rd cha i n g S in g l e l i ne o f co de can do a l a rge
syste m.
a t so me con clu si on . E vo l ved sin ce e a rl y 70 's. m atch a l l th e p re mi ses. n um b er o f co mp uta ti on s.
P ro vi de s th e re a son i ng a bi l i ty
Ded u ce s so m eth i ng fro m th e d a ta. P ro g ram me r ne e ds to p rovi d e o nl y the Works wh ere the r are a l a rg e No n oti o n o f Ma i n P rog ram .
to m a ke con clu si on s.
ru le s & n ot worry ab o ut the seq u en ce. n um b er o f co rre ct re sul ts. P re ce de n ce i s ri g ht to l e ft fo r
fo rm u la s.
S ma l l d e di ca te d gro up o f fo l lo wers.


Concept: Correlation between Language generation &
Generation Characteristics Features
hardware generation
Definition:
Early 1950’s
1st Machine languages. Machine dependent
Summary Points:
Late 1950’s § Correlations can be drawn between the developing
2nd Assembly languages. Machine independent generations of hardware & programming languages.
§ Vacuum tube based machines didn’t provide
1960’s-1980’s sufficient power to enable higher-level languages to
3rd Considered high-level languages. Introduction of compilers in addition to being machine evolve. The transistor allowed the assembler to come
independent into being (Fortran & Cobol)
§ Processing power has allowed languages to become
1980’s-1990’s
more intelligent, user friendly & processor
4th Operating system independent. User-friendly, easy to use for non-programmers. Portable
independent.

1990’s – Example:
5th Artificial intelligence, Neural networks, Quantum computing

Concept: Reasons for development of programming
Generation Characteristics Features languages

1930’s – 1950’s Definition:
1st Vacuum tubes, analog computers, late 1940’s first electronic machines begin to be conceived.

Summary Points:
1950’s – 1960’s § Repetitive standard programming tasks
2nd Transistors replace vacuum tubes § Desire to solve different types of problems
1960’s § Expansion to meet different needs as new hardware
3rd Integrated circuits replace transistors & peripherals (technology) have emerged
§ Greater productivity
1970’s - 1980
4th First microprocessor is designed. CRAY supercomputer is designed.

1980’s – 1990
5th First WAN is established, parallel processing introduced, computers become portable
(desktops)
6th 1990’s
Pentium processor is released, networks become the norm


Concept: Imperative Programming Concept: Example of Imperative Programming C Concept: Adv/Disadv. Imperative programming
§ easy to understand since it corresponds with
Definition: Commands are performed to affect the every day life eg. cooking, giving directions
state of the program. Data represents the state. void find (int sum) § not too many tricky concepts
Processing & data separated. { § straight-forward to implement efficiently on
Summary Points: News Article: Y/N int i, current, total; computer hardware
§ data sent to CPU for processing & stored in for (i = 1; i < sum; i++) { § doesn’t fit all real life situations eg. medical analy
memory total = 0; sis using intuition, communication with people
§ uses main control structures current = i; Disadvantages
§ creates variables for storage do { § runs commands that change (side-effect) the
§ does the same old thing but faster due to ad- total = total + current; values of variables until the desired output is achieved.
vances in hardware technology current = current + 1; § can only be perceived by understanding all of the
§ distinct beginning & end } while (total < sum); variables that are used by all commands that changes
§ re-usable code is NOT an integral part of the if (total == sum) the variables (can be hard to debug)
imperative language (but desirable). print (i, current - 1); § Reasoning about imperative programs can be hard
Example: } and debugging and maintenance can be difficult.
§ C }
§ Visual Basic, QBasic
Concept: Logic Programming Concept: Prolog Concept: Expert Systems

Definition: also known as non-procedural, eat(lion, dog). eat(lion,bird):- § Performs functions that normally would be
declarative. Associated with artificial intelligence et(lion,X), performed by a human expert in that field.
eat(dog,cat). at(X,bird) § Do not reach definite conclusions but weigh up
Summary Points: eat(cat,bird). the evidence & present possible conclusions.
§ In the other paradigms control flow is explicit via § uses facts & rules, probabilities
conditional statements, loops and function calls, etc.
eat(bird,spider). § uses heuristics – rule of thumb that are generally
§ In contrast, logic programming uses the resolution eat(spider,fly). accepted as true within a specialist area
process with its implicit backtracking so programs are § conclusions reported as probabilities
easier to write, understand and maintain. eat(lion,bird) § Understands how a human expert reasons
§ The downside is that implementing backtracking is § Stored in a knowledge base
costly in time and space compared to implementation eat(lion,X) eat(X,bird) § Expert system shells provide the framework
approaches for other paradigms. § It cannot learn new information
§ eat(lion,dog) eat(dog,bird)
Example:
eat(dog,Y) eat(Y,bird)
eat(dog,cat) eat(cat,bird)


Concept: Expert System Hugin Lite Concept: Prolog Coding
Probability Result parent(marta,joe).
parent(marta,jules).
Cost parent(marta,lil).
parent(nick,jules).
parent(nick,joe).

mother(Mother,Child) :-
Sick Dry Treat female(Mother),
parent(Mother,Child).
father(Father,Child) :-
Sick Dry male(Father),
Loses parent(Father,Child).
grandparent(Grandparent, Grandchild) :-
Harv parent(Grandparent, X),
Loses parent(X, Grandchild).

?- parent(tezza,marta).

Concept: Functional Programming Concept: Functional code examples Concept: Functional Language use Lists
Definition: A program that consists entirely of (define (square num) § In functional languages, the list is the most
functions eg. Dr Scheme (* num num) important data structure. A list can consist of zero
Summary Points: or more elements, list can also be nested
§ Functional programming tries to resolve problems ) § (list 3 4 56) a list of three numbers
with variables by making the whole program a function (define (factorial n) § (list “a” “j” “o” “p”) a list of four characters
from some input to some output. (if (eq? n 0) 1 § (list ) an empty list
§ no assignment statements. Variables don’t change (* n(factorial (- n 1))) § (list (list 2 3) (list 5 6)) a list within a list
§ all you need to understand is how functions call ) ; type this (member 3 (list 3 4 56))
each other. ) ; example of using a list in DrSchem
§ no need for a programmer to understand many ; fibonacci function in which fib(1) = 1 and fib(2) = 2 (define (member e l)
different commands to work out what the program will (define (fib n) (if (empty? l)
do. (if (eq? n 1) 1 #f
§ enforces use of modules (re-use of code) (if (eq? n 2) 1 (if (eq? e (first l)) #t
§ not widely used nor accepted (+ (fib (- n 1)) (fib(- n 2))) (member e (rest l))
§ very mathematically oriented ) )
§ runs more slowly; not suitable to tasks of an ) )
imperative nature ) )
§ no global variables only local variable
§ difficult to translate a process into a function


Concept: Programmer’s Productivity Concept: Programmer’s Productivity Concept: Programmer’s Productivity
Definition: the choice of a paradigm may have impact Effect on maintenance: languages (OOP, functional) Efficiency of coded solutions: Imperative languages are
upon the productivity of the programmer. that enforce writing in modules have positive impact fastest due to advances in hardware technology but
Summary Points: upon maintenance. not due to advances in software technology.
Learning Curve: Learning curves of new paradigms are § modules already tested, can be re-used, blackbox § imperative languages more apt for technology
steep. OOP is now widely accepted & learned early. § easy to locate the coding to be modified within the other languages, although slower, may have less
§ functional is NOT widely accepted modules for maintenance development time
§ logic programming in NOT widely accepted
§ ‘marketing’ strategies need to be put into place to approach to testing: languages (OOP, functional) that
gain faster acceptance. enforce creation of modules increases productivity
§ learning 1 language can carry over to another when testing.
§ many languages require more expertise than § modules are independent & have already been
others tested. Don’t have to be re-tested if unchanged
Speed of code generation: Languages that increase the § modules inherit in OOP. Inherited modules do not
speed of code generation increases productivity. need or little testing.
§ machine language is fastest but longest to develop § amount of testing is dramatically reduced, hence,
§ OOP more efficient but slower to execute increasing the productivity especially if the modules
§ Imperative languages fastest but due to tech. are re-used.
§ Others reduce development time.
Concept: You may want to add object oriented Concept:
here.

§ § One will undoubtedly be given a scenario in
the HSC Exam where one needs to identify
the best paradigm for the problem and be
§ § able to justify the choice at considerable
length.

§ §

Example: Example:




§ § §

§ § §

§ § §




§ § §

§ § §

§ § §


Sdd HSC Summary

More Related Content

Viewers also liked

Similar to Sdd HSC Summary

More from mary_ramsay

Recently uploaded

Sdd HSC Summary