Sdd HSC Summary

SDD HSC Social & Ethical Issues Page 1 of 43

HSC Software Design and Development

Mindmaps

and Summary Sheets

SDD HSC Social & Ethical Issues Page 2 of 43

M ethods of Implementation

T rends in Software Development

Approaches: Com merical System s

CASE T ools

Socia l & Eth ical Issues

Rights Responsibi l i tes of Developer

Prevention of spread of virusesScan rem ovable media before use

Careful vetting of em ai lNot mixing hom e/work appl ications

Latest vi rus defin itions

Qual i tyre liab il i ty

ease of useconsistency of user

in terfacedocumentation

adhere to sftwre standards

Response to Problem sIdenti fy the development problem

Understand the development problemDesign & Test a solutionImplement the solution

Code of ConductAcknowledge a l l contributors

Clearance to use copyrighted m odules of code

Privacy, securi ty of data secretsUse of appropriate prom pts

Rel iabi l i tyPerform wi thout fai lue

T horoughly check input dataKeep to wel l defined & stand process for

sftwre devlopment

Piracy & Copyright

Software M arket

Exam ples

Inte l lectual PropertyPlagiarismShareware

Publ ic Dom ainOwnership vs L icensing

Copyright LawsReverse Engineering

Decompi lationLicense Condi tions

Network usePiracy & copyright laws

Copyright laws & license agreem ents

Gov't, Business, IndividualsDriven by m ore sophisticated

hardware & peripheralsM aintain ing market posi tion

Effect on marketplace

Improve current appicationIntroduce new innovation sftwareM aintenance, support of existing

product

Enticed to upgrade appl icationCrossgrade by competing productsIncrease com puter power, storage &

output devices

National / In ternational Legal ActionYear 2000 problemCom puter vi ruses

Rel iance on software -> microwave

Software Development Approaches

Direct conversionParal le l conversionPhased conversion

Pilo t Conversion

•OutsourcingForm al to Ad-hoc

Popular Approaches: Accessib le to large num ber of employees

Smal l end users: off the shel fPopular languages

Employm ent TrendsNetworked software

Off the shel f Packages

Geared to support speci fic activi ties of the System Dev.

Cycle eg:T ext edi ting, test-data generation, document preparation, flow chart.Versioning: v1.0 v1.1 v1.3 v2.0

Data dictionary

Structured ApproachPrototyping

Rapid Appl ication developm entEnd-user developm ent

Com bination of Approaches

Define the problemPlan the solutionBui ld the solution

Check the solutionM odi fy the solution

Constra ints:Financia l

OperationalT echnical

Schedul ing

Data Flow Diagram

IPO ChartAlgorithms

System Flow

Information gathering toolEvolves into ful ly working

program

Reuse of existing m odules in 4th Generation Languages

Project scope is constra inedAutomated tools used

Development & Implementation of Software Solutions

SDD HSC Social & Ethical Issues Page 3 of 43 Concept: Social & Ethical Issues: Rights responsibilities of software developers code of conduct / practice: § acknowledge all contributors § clearance to use copyrighted modules of code § one should not discuss employer’s or clients requirements or specifications without consent § one should maintain the privacy of individuals § one should use non-threatening prompts or message boxes. reliability: the ability to perform without failure. § thoroughly check input data § keep to well defined & standard processes for software development

Concept: Social & Ethical Issues: Responsibilities continued: quality: measured by a number of criteria: § reliability § ease of use: comfort of the user § consistency of user interface: placement of similar items in the same place § documentation: process & product are of high quality § sticking to software standards response to problems: overcome problems in an order- ly fashion. § identify the problem § understand the development problem § design & test a solution to the develop. problem § implement the solution

Concept: Social & Ethical Issues: Responsibilities continued: prevention of virus spread: § scan removable media before use § careful vetting of email § not mixing development on home & work machines § use latest virus definitions Some issues for developers: § portability § backward compatibility § modularity § security § cost constraints § operational reliability with other common software

Issue:

Rights of software developers:

Responsibilities of software developers: Concept: Social & Ethical Issues: Piracy & copyright: intellectual property: a personal ownership of the creative ideas that develop from someone’s mind. plagiarism: the theft of ideas & expressions of another person. Often code is collected for a range of other sources. shareware; software that is distributed for trial use before purchase. public domain: freeware which can be copied & distributed freely. No payment is due. Still covered by copyright. ownership vs. licensing: payment means the purchaser has the right to use the software but NOT the ownership of the software

Authorship Reliability Quality Response to problems Code of conduct Viruses

Protection of their product against theft & modification Protection against operating system, hardware, & program problems which may make their product unusable. Codes to ensure others develop programs that follow the same high standard Not to be harassed with trivial problems that could have been solved by the user reading the documentation. All developers follow the same ethical standards. Protection of the developer’s products by users through the use of good current antivirus products

Acknowledge authors & sources particularly in a devel-opment team Check that the product works with the hardware & OS that they specify. Ensure there are no run time errors when installed & run as directed. Use thorough testing procedures & error checking code Meet the user’s expectations as much as possible Provided troubleshooting manuals, online help. Provide customer support. Quick response to major or critical problems. Make bug fixes freely available to users. Follow the standards set by members of the profes-sional association to which they belong. Ensure they do not distribute viruses with their products or as part of their customer contact such as through emails.

SDD HSC Social & Ethical Issues Page 4 of 43 Concept: Social & Ethical Issues: Piracy & copyright: continued: reverse/backward engineering: the process of reading source code & translating it to an algorithm which then can be modified & recoded elsewhere. decompilation: where object code is translated into code that can be more easily studied by a programmer needing to understand the processes carried out. licence conditions: spells out exactly how the software may be used by the licence purchaser. It is a legally binding contract. network use: many programs are available for network use. Licence indicates how many may use it or it may be a site licence. § centralized: single copy on central server § distributed:individual copies on individual machines

Concept: Social & Ethical Issues: Software piracy & copyright laws Warez commercial packages that have been illegally copied or pirated & made publicly available. Pirateers have found a way to by-pass the copy-protection. § distribution within Australia is illegal § deprives the legitimate copyright owners of money § some nations have refused to sign a universal copyright law relationship -> copyright laws & licence agreements: § licence is a contract § single-user licence § multi-user licence § network licence Business Software Association of Australia § educate people § assist in software management § help prosecute those in breach of licence agreemnt

Concept: Social & Ethical Issues: Software Market: § gov’t, business & private individuals make up the software market. § gov’t, businesses are more likely to need custom written software § software market driven by more sophisticated hardware & peripherals. eg. as computers became more powerful, word processing features advanced. maintaining market position: aim is to make a profit. § improve the current application § introducing new & innovative software applications § maintenance & support is very important for sur- vival of a software company § active research & development program in major software development companies. § reputation as an ethical developer § bug-free software (or as close as possible)

Concept: Social & Ethical Issues: software market Effect on the market place Definition: software production is a multi-billion dollar industry. Summary Points: News Article: Y/N § enticed to update their applications § crossgrade: change to a competing product eg. go from Word to WordPerfect word processor § more complex software needs more computer power. Example: eg. gaming, video editing, digital editing More hard disk storage, RAM & processing speed

Concept: Social & Ethical Issues: software market Significant social & ethical issues: National & international legal action resulting from software development: § trumpet software vs OzEmail: OzEmail distributed Winsock with their distribution disks but failed to ad- vise customers they had to register with Winsock. Some documentation was omitted or chaned. OzEmail was ruled against. § 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. Public issue: § Y2k millennium bug § computer viruses

Bibliography: Main: Folwer’s HSC SDD text

Supplementary: Wilson’s HSC SDD text

SDD HSC Software Development Approaches Page 5 of 43 Concept: Software Development Approaches: Approaches: commercial systems: structured approach: follows the software develop. cycle. It looks at the whole problem & divides it into steps that can be systematically followed to arrive at a solution. § it is time consuming but appropriate for complex problems. § often a team is involved: system analyst, programmers, graphic designers, managers, trainers, users structured approach: define the problem-> plan the solution-> build the solution-> check the solution-> modify the solution define the problem: thoroughly understand & define the problem itself. § interviews, collect data, observation, documents, questionnaire, surveys § specific requirements drawn up

Concept: Software Development Approaches: structured approach continued § it takes little to fix a mistake at this stage but becomes more expensive in the latter stages § feasibility of a software solution (constraints) planning the solution: involves a further, more in depth understanding of the needs of the users & a choice of a method(s) to solve the problem. § planning the data & program structures § designing algorithms § planning the user interface § scheduling the project – Gantt chart § choosing a programming language § dataflow diagrams, IPO charts used as tools § mostly involves the design & checking of algorithm & interfaces

Concept: Software Development Approaches: structured approach continued: building the solution: the programming, coding & testing phase. Everyone is involved. § top-down approach / step-wise refinement § peer checking, desk checking § runtime testing checking the solution: a continuous part of the SDC (system development cycle). § acceptance testing: measured against the original specifications § real data used § alpha / beta testing § screen design, intuitive § staff training § error handling within the program

Concept: Software Development Approaches: structured approach: continued: modifying the solution: modifying the solution from checking the solution. Further testing takes place on the modifications. Program is either accepted or modi fied further. § significant changes at this stage can be quite expensive § should only be carried out if small or crucial § in extreme cases, the analyst could recommend the SDC start all over again.

Concept: Software Development Approaches: structured approach: Advantages § easier to write because it is broken into chunks § easier to understand because of the use of modules; can be easily tracked & connections seen § easy to test & debug each module separately § easy to modify because only some modules need to be changed.

Concept: Software Development Approaches: structured approach is used when: § project is large scale, complex & is best solved using modularisation § development budget is large § time available is considerable § a easy program to debug, write, understand & modify is required. § a project development team is involved.

SDD HSC Software Development Approaches Page 6 of 43 Concept: Software Development Approaches: Prototyping Definition: involves building a working model that is evaluated by users. It generally has screens but little processing. Summary Points: News Article: Y/N § it can become the actual solution § can be used as an information gathering tool that can be used in another program § useful where a lot of computer interaction is required eg. multimedia, internet § user gives feedback via a prototype § reduced documentation & faster development compared to structured approach. Use prototyping when: § development is small scale & small budget § a smaller team needed § less time available § help develop another program

Concept: Software Development Approaches: Rapid Applications Development Definition: any method of software design that uses tools to quickly generate a program for a user. Summary Points: News Article: Y/N § uses existing modules to create a solution existing modules need little or no testing § may reuse code § may use CASE tools & templates § requirements of project are well understood § scope is well constrained, focused. § includes adding modifications to existing software Use prototyping when: § very small team, low budget & minimal time § small scale projects § a small range of coding languages

Concept: Software Development Approaches: End-user development Definition: where the user adapts existing software tools to suit their needs or to obtain a solution to a problem. Summary Points: News Article: Y/N § a larger number of programs allow the users to create their own solution § very informal, little documentation § buttons & macros can be used to a limited degree § disadv. end users within the same organization often duplicate processes unknowingly. Use end user development when: § development involves the user § it involves existing software solutions § it involves very little cost or time § it involves small problems

Concept: Software Development Approaches: Combination of approaches § Using combinations of the 4 approaches can be

carried out. § eg. the problem could be split in two & the

sections worked on separately using different approaches.

§ The ultimate objective is always to produce a

properly documented solution to the problem.

Concept: Software Development Approaches: Methods of implementation parallel: the old & the new program work together for a period of time. direct cut-over: the new program immediately replaces the old program phased: one or more tasks of the new program are gradually implemented until the new program takes over all tasks of the old program. pilot: one section of the organization uses the new program & all other sections continue with the old program until a decision is made to put the new program into place across the whole system.

Concept: Software Development Approaches: Methods of implementation Adv. & Disadv. parallel adv: 2 programs can be compared. Fixing is simpler because old one can be used in emergency parallel disadv: user stress both systems operated. Confusion between programs. Dual costs - more expensive. Large changes in procedures can cause confusion. direct adv: reduced implementation costs. Less pres- sure on users – only 1 program in place direct disadv: data transfer done quickly. No fallback. User stress in training before new program in place. phased adv: each task individually tested. Training is easier phased disadv:difficult to separate the old & new tasks 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.

SDD HSC Software Development Approaches Page 7 of 43 Concept: Software Development Approaches: Trends in software development: outsourcing: hiring an outside organization to handle all or part of software serverices. § no expense of a full Information Tech. department § effective use of scarce technological assets § difficulty of breaking unsatisfactory contracts § may not understand the ethos of the organisation § may feel it lost its control of is system popular approaches: ranges for ad-hoc to formal. § web-page editors have encouraged end users § customising off the shelf software § software accessible to large number of employees § greater distribution of code libraries § increasing use of hypermedia § increased use of authoring languages

Concept: Software Development Approaches: Trends in software development continued: popular languages: § structured environments: C++, Visual Basic, Java § informal: spreadsheets, web page,macro recording databases, SQL § 3rd generation: COBAL & Fortran still popular § they all have a formal set of rules called syntax § all use constants, variables & operators § some are easier to use than others and some run faster than others. Employment trends: § less likely to be permanent employment § will tend to be contract work to the business or software development company § increasingly high educational requirements

Concept: Software Development Approaches: Networked software Definition: software written for use on centralised networks. Needs to interact with the network oper- ing system which handle the security & communications tasks. Summary Points: News Article: Y/N § business moving toward personal computers that are networked. § security is of particular importance especially with financial transactions & the Internet. Network software: § user interface and the system § application: meets the needs of the end user § database management: manipulation & management of data on the network § network: the means by which communications takes place

Concept: Software Development Approaches: Customised off-the-shelf packages Definition: software that is purchased off the shelf & can be modified to fit a scenario in a business eg. book keeping software. Summary Points: News Article: Y/N § able to create a software solution from an integrated package eg. spreadsheets, Database, graphics, word processing § customizable interface § customizable reports § conversion of old data to the new system § lends itself to prototyping approach or an end- user approach. Example: MYOB, Creating a relational database for a specific task. eg. Dean’s Merit Awards

Concept: Software Development Approaches: CASE tools Definition: computer assisted software engineering to help in the task of software development & maintenance. Summary Points: News Article: Y/N § general software to aid the software development can be considered as CASE tools eg. word processor, spreadsheet, graphics software § data dictionaries § specialist software does exist but we have seen no practical examples. § management of software development includes versioning the changes eg. v1.0->v1.1->1.1.1->1.2-> 1.3->v2.0 § documentation generation using CASE tool § test data generators CASE tool

Bibliography: Main: Fowler’s HSC SDD text

Supplementary: Wilson’s HSC SDD text

SDD HSC Software Development Approaches Page 8 of 43 Concept: Software Development Approaches: Definition: Summary Points: News Article: Y/N § § § Example:

Concept: Software Development Approaches: Definition: Summary Points: News Article: Y/N § § § Example:





SDD HSC Defining & Understanding the Problem Page 9 of 43

Defin ing the Problem

Design Speci fications

M odell ing

Com municationSDC Defining & Understanding the Problem

Identi fying the problemProblem defini tion / feasib i l i ty study

NeedsObjectivesFeasibi l i ty

Is i t worth Solving?Constra ints

Budgetary considerationsOperational considerationsT echnical considerations

Schedul ingPossible Al ternatives

Socia l & Eth ica l considerations

Scope of the pro jectData design

Overal l program designInterface designProcess Design

Cross-reference with requirements defin i tion

Implementation & testingDeveloper's Perspective

Data typesVariables

AlgorithmsUser's perspective

Scope:How the software fi ts in .Defines the boundariesForm s of input/output

dataDescription of processing

Data Design:Identi fy data objectsIdenti fy data types

Identi fy fi le structureCross reference

Overal l DesignStructure Charts

Includes: modules & the in teractions between m odules

Interface Design:Hum an-machine interface

How the user in teracts.Speci fications that describes

the in terfaces between m odules, program & external

devices

Process Design:Each module described in deta i l

Description of the InterfaceAlgorithm that desribes module

Local data structuresAny restrictions / lim i tations

Cross Reference:Ensures requi rem ents m et by

software.Indicates which modules m eet

particular requi rements.

Implement. / testingGeneral processes for

testing outl ined.Insta l la tion onto si te is

careful ly planned

Dev. Perspective:

Converts cl ient's wishes to a

program .

Data types:Is able to cater

for storageVisualised by the

program mer & expressed as a m odel on paperReflect the data in the problem.

Variables:Global , local

Appropriate nam e of i tem

Algorithms:Break down problem

into smal ler problem s.T op-town approach

Data Flow DiagramsIPO diagram s

Linear storyboardHierarchial storyboardNetwork storyboardHybrid storyboardSystem flowchart

Screen designLimi ted Prototype

Decision treeDecision tableStructure chart

Need to em power the userGives sense of ownership

Acknowledge user's perspectiveAccepting feedback

System Development Cycle:Defining Understanding the

Problem

SDD HSC Defining & Understanding the Problem Page 10 of 43 Concept: Define Understand the Problem: Defining the problem: Definition: Problem definition involves examining the needs of the users, objectives that the solution is to meet, the boundaries within which the solution has to work and whether it is feasible. Needs: needs of the user, needs of the system (data types, storage of facts, perform certain processes & the output need). Objectives: are aims which are measurable. eg. maximum response time. Boundaries: where outputs leave one system & pass on to the next system. § are limits, borders § can be hardware/software requirements Is it worth solving?

Concept: Define Understand the Problem: Determining the feasibility of the solution Definition: determines whether a problem is worth solving. Constraint is a limitation placed on something. financial feasibility: the ability to develop a program within the money allocated for the project. § the additional income &/or projected savings need to be more than the cost of implementing the solution. operational feasibility: refers to the skills & resources needed to complete and maintain the program. § eg. artificial intelligence may be worthwhile but the skills don’t exist yet. § meets the needs of the organization. May refine a worker’s role. technical feasibility: the availability of hardware and software for the product to meet the needs of the program. scheduling feasibility: refers to time requirements. There is usually a firm completion date. eg Y2K bug.

Concept: Define Understand the Problem: Determining the feasibility of the solution continued: Possible alternatives: looks at all the other options available to solve the problem. § could include leaving the system unchanged § rough cost of each alternative § adv. & disadv. of each alternative § analyst makes a recommendation with justification social & ethical considerations: impact upon people be it lifestyle or work practices. § right to privacy: sensitive personal information § code from other sources need to be dealt with as per copyright.

Concept: Define Understand the Problem: Design Specifications: Definition: lays down the guidelines for development and give a yardstick to measure the success of the project. Some aspects include: scope of the project: how the software fits in with the whole system. § forms of output / input § description of processing to convert input to output § any special processing needs data design: identifies the data objects required & the resulting data types. § file structure & access covered here cross reference: checking that data items are related to their respective files / modules.

Concept: Define Understand the Problem: Overall program design: Definition: One steps back and takes a look at the overall design of the program. Usually quite general. § structure charts: includes modules & the interactions between modules. § context / dataflow diagrams § input processing output charts § system flow chart

Concept: Define Understand the Problem: Interface design: Definition: the interface between the user & the program. human-machine interface § give control of the program to the user § enable access to other parts of the program § consistent screen design eg. navigation § simplicity: easy to learn and use specifications: that describe the interfaces between modules, program and external devices. eg. printing from a program

SDD HSC Defining & Understanding the Problem Page 11 of 43 Concept: Define Understand the Problem: Process design: Definition: a description of processing. § each module is described in detail. § a description of the interface. Includes machine- human centered & machine-peripherals § algorithm that describes each module § identifies any local data structures within a module § any restrictions / limitations on the module

Concept: Define Understand the Problem: Implementation & testing: Definition: implementation & testing needs to be planned out & specified before they are used. § general processes for testing outlined. § installation onto the actual site needs to be carefully planned.

Concept: Define Understand the Problem: Developer’s perspective Definition: white-box: is concerned with what happens & how it happens. Input & output are equally important. data types: § converts client’s wishes to a program § choose data types that cater for respective storage § visualised by the programmer & expressed as a 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 meaningful name.

Concept: Define Understand the Problem: Modeling: Definition: a system can be represented in some way to show its structure. § data flow diagarm § IPO chart § linear storyboard § hierarchical storyboard § network storyboard: modules may be accessed directly by other modules. § hybrid storyboard § system flow chart § screen design § 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: Communication Definition: should interact with the user throughout the process. Summary Points: News Article: Y/N § it empowers the user § gives the user some sense of ownership § acknowledges the user’s perspective § demonstrates the ability to accept feedback.

Bibliography: Main: Fowler’s SDD HSC text

Supplementary: Wilson’s SDD HSC text

SDD HSC Defining & Understanding the Problem Page 12 of 43 Concept: Define Understand the Problem:

Concept: Define Understand the Problem:





SDD HSC Defining & Understanding the Problem Page 13 of 43 Concept: Define Understand the Problem:




SDD HSC Planning & Design Page 14 of 43

Problem Solving Strategy Design Concepts

M odules & Functions

Arrays (Basic)

Sorting & Searching

String Processing

Records &Col lections

SDC Planning & Design of

software solutions

Structured Program m ingFunctional Decomposi tion

Use of M ain moduleUse of sub m odulesWri tten separate lyT ested separate ly

Should be independentRe-use of m odules

M aintenance on som e m odules only needed

System Development Cycle:Planning & Design

Identi fication of appropriate modulesIndenti fication inputs, processes &

outputsT he scope of variables local preferred

Passing of param etersT horough testing

Desk checking using trace tablesField testingPrototyping

External docum entationInternal documentation

Listing assum ptions

Decomposi tion, reusabi l i tyFunction libraries

Cal l , re turn mechanismsFunction anatom yFunction namesFunction input

Function outputFunction processing

Local varablesBoolean functions

Nam ing, creating arraysHolds single data typeArrays of fixed length

Indexing arraysT raversing arrays

Swapping e lem entsFinding largest value in array

Finding posi tion of largest va lue in arraySim ple l inear search

Searching arrays:L inear searchBinary searchSorting arrays:

Bubble sortSelection sortInsertion sort

See Pow er Point Presentation

String concepts:String m anipulation functions are

stored in librariesConcatenation of 2 strings

trimStringcom pareStrings

toLowerCase, to UpperCasestringConta ins

RecordsDatabase terminology

Object Oriented term inologyUsing records

Nested recordsCol lections

Defin ing the storageDefin ing the functions

SDD HSC Planning & Design Page 15 of 43 Concept: Planning & Design: structured programming & functional decomposition § structured programming consists of a main module which activates sub-modules. aka modular program-ming (aka = also known as) § functional decomposition: is the breaking down of a complex problem down into functions. § a well written module can be used over & over § modules should be independent Some requirements to generate software solutions: § identification of inputs, outputs & processing § id & definition of required data structures § an understanding where/when to use random numbers § thorough testing of the solution

Concept: Planning & Design: design concepts identification of appropriate modules: § read main module first to get overview of the algorithm. Examine sub-modules to get more detailed information. § top-down: design main module first, then the sub modules. also known as (aka) stepwise refinement

Concept: Planning & Design: design concepts identification of inputs, processes & outputs: Input: § type of data? § source of data? § method of data input? § instructions to computer to handle data input? Process data: § what steps are taken to process the data? § are loops and/or selection structures needed? § instructions to computer to handle data processing? Output data: § type of data output? § method of data output? § instructions to computer to handle data output? IPO Chart

Concept: Planning & Design: design concepts: The scope of variables: it is preferred that variables can only be used in the module in which they were created. (local variables vs global variables) global variables: accessed by all modules at the same time without the need to pass their values around. § use of global variable often result in errors be-cause a module may unknowingly change the value. thorough testing: one must provide sample input data values, run one’s algorithm using this data & check that the output is correct. desk checking: one keeps track of all variables & values on paper & adjusts the values as one goes line by line through the algorithm. § all branches must be tested as well as the conditions of all loops. § use trace tables with desk checking

Concept: Planning & Design: design concepts: continued: field testing: give the completed software to a group of people to try out under real working conditions. § bugs are reported to the vendor § bugs are fixed by the vendor & re-released with a higher version number. § it is frowned upon when software is rushed to completion that still have numerable bugs. prototyping: a partially complete software product. § usually contains a user-interface & some of the fundamental routines. § allows client feedback § cheaper than producing a full product § allows one to clarify some of the requirements Test data: § Legal & expected values § illegal but expected values § legal but unexpected values

Concept: Planning & Design: design concepts continued: External documentation: documentation for the user in print form. Internal documentation: written within the algorithm itself. § can be a written block of comments that appear before the actual algorithm. Introduce the reader to the algorithm & includes a brief description of its purpose. § can be single lines of comments embedded in the algorithm at appropriate places. § can use comments to break up the list of coding for the sake of readability. Listing assumptions: included in introductory comments. It tells readers what the algorithm supports & what it omits. § eg.when reading data from a file, one may say that you assume the file exist.

SDD HSC Planning & Design Page 16 of 43 Concept: Planning & Design: Modules & Functions General Issues decomposition & reusability: the algorithm is broken down into smaller chunks. § if correctly written, can be reused in other algorithms that have similar tasks: re-usable. function libraries: collections of well-tested & reusable functions. § functions within the library can be activated to do much of the processing. § most programming languages have ‘standard function libraries’ call and return mechanism: subprograms are activated by being called. Once the subprogram is finished it returns back to the place from which it was called.

Concept: Planning & Design: Modules & Functions Function anatomy Definition: a function can have up to 4 parts. It must have a name & a block of instructions. It may have input and/or output but is not mandatory. function names: short, readable & meaningful. It tries to indicate what the function does. eg.’findBiggest’ function input: is the data passed to it by the calling code. § also known as arguments or parameters. function output: we output information from a function by ‘returning’ it. eg. return bigNum § usually the last instruction in a function but not necessarily so. § when return is activated the function is ended at that instant. also known as: short circuiting

Concept: Planning & Design: Modules & Functions Function anatomy continued: function processing: a function should do something. It does it something between keywords like BEGIN & END. local variables: created within a function § no conflict between local variables of one function and those of any other function. § are not shared § the same name can be used in many functions Boolean functions: a Boolean value is either true or false. § a function that returns either true or false is called a Boolean function. § called ‘query function’ because they usually perform a test on the value of their input. § often have a name starting with ‘is’ eg. isVoter

Concept: Planning & Design: Arrays: basic concepts

See Power Point Presentation on arrays

Concept: Planning & Design: Advanced sorting & searching techniques

See Power Point Presentation on searching, sorting

Concept: Planning & Design: String Processing 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. compareStrings: test the alphabetical order of two strings. toLowerCase, to UpperCase: changes all the characters 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

SDD HSC Planning & Design Page 17 of 43 Concept: Planning & Design: Records & collections Definition: a record can hold more than one data type. A record has fields & each field is an array. eg. Person is a record containing name, a string age, a whole number END § a record encapsulates the two variables because the Person record is like a capsule. § a record is the encapsulation of several variables as fields in the one structure § the definition of a record is like a template that shows how a particular type of record is structured. Nested records: we can use records within records. Date is a record containing… Person is a record containing a date (+ other fields)

Concept: Planning & Design: Records & collections collections: refers to the storage & management of several or many records. § collections are stored in an array of records for our purposes. Defining the storage: is an algorithm that creates an array of records eg. 20 Stock records Defining the function: defines the fields of a record. files: are blocks of data treated as single units sequential access: one must go through each record in sequence to get to it. Like a cassette music tape. random access: goes straight to the record location. Like a music track on a compact disk.

Concept: Planning & Design: Selection of language to be used. Event-driven software: uses actions to trigger an event eg. mouse click, key presses Features: menus, buttons, other objects Program logic: polling to check status of events; event parsing to execute the events that are activated by the user (Wilson text) Uses: games, GUI, computer controlled systems sequential programming: follows a set of steps to solve a given problem. Features: standard control structures, variables used, assignment is to transfer data from one memory location to another. Program logic: order of execution is defined by the programmer. Linear execution of instructions. Uses: file & data handling programs such as word processors, databases & spreadsheets.

Concept: Definition: Summary Points: News Article: Y/N § § § Example:


Bibliography Mostly: Fowler SDD HSC text book

Supplementary: Wilson SDD HSC text book

SDD HSC Implementation Page 18 of 43

Interface Design

LanguageSyntax

CPURole

T ransla tionMethods

Program DevelopmentT echniques

Documention Software Solution

HardwareEnvi ronment

EmergingT echnolog ies

SDC Implem entation

o f Software Solu tions

System Development Cycle:Implementation

Design of Ind ividua l screensIdentifica tion o f data requi redDBM S can produce on screen

VB can design own screenDesign of he lp screensAudience Identi fica tion

Consistency in approach

BNF, EBNFRai l road diagrams

Mul ti -d imensional arraysArrays o f records

Machine codeInstruction form at

Use of registers accumulatorsCounter, fe tch-execute cycleAddresses of ca l led routines

L inking, use of DLLs

Methods of T ransla tion:Com pi la tion

Interpre tationIncrementa l interpre tation

T ransla tion processLexical ana lysis (scann ing)Syntactic analysis (parsing)

T ype checkingCode generation

T he l inkerT he loader

T he optimiserAdv. Disadv of com piler,

interpre ter, incrementa l com pi ler

Structured approach to a complex solu tion.

One log ica l task per subroutineStubsFlags

Isola tion of errorsDebugging output statements

Elegance of so lu tionWri ting for m aintenance

Detecting & correcting errorsSyntax errorsLog ic errorsPeer check

Desk checkingUse of expected output

Run-tim e errorsDebugging too ls

BreakpointsResetting variab le contents

Program tracesSing le l ine stepping

Form s of docum entation:Process d iary

User docum entationFunctional description

Insta l la tion guideIntroductory Manual

System Adm in. manualUser manualOnl ine help

Sel f-docum entation of the code

T echnica l Documentation:Source codeAlgorithms

Data DictionarySystems docum entation

Future m aintenance of the codeSoftware to assist in the documentation process

CASE tools Hardware requi rementsMin imum configura tion

Possible additiona l hardwareAppropriate drivers, extensions

HardwareSoftware

Effect o f em erg ing technologiesEffect on human environment

Effect on developm ent process

SDD HSC Implementation Page 19 of 43 Concept: Implementation: Design of Individual Screens Definition: a good program can be considered use- less if the interface design is poor. Some factors: § type of data to be presented: input or output § type of audience eg. age, teenagers, business § assistance required by the user: degree of Help § consistency between screens § type of application: graphics, Maths drill § degree of interaction by user: game, database § number of screen elements to be included § appropriate messages are critical to prevent users taking destructive action. eg. Are you sure you wish to Delete this file?

Concept: Implementation: Major aspects for the user interface: § consistency: similar operations should be achieved the same way § familiarity: use words that users can understand § forgiveness: allow users to recover from errors without a major crashes § robustness: should handle unusual procedures without crashing § feedback: should communicate with the user when necessary § guidance: should provide some form of Help

Concept: Implementation: Some elements used to support user interaction § buttons: click, double click § switches: alters screen structures eg. background § menus: pull down § indicators: activated to show action is occurring eg. percentage indicator bar for installation § displays: show data § sliders: moved to alter views or scales § colour: use and misuse § greyed colours to show active/inactive windows § use red for error messages

Concept: Implementation: Identification of data required. Definition: The way in which data is displayed can help the user relate to the process being carried out. Summary Points: News Article: Y/N § sequential: one screen follows another § event-driven: user input decides order of the screen display. § text can be: menus, labels, arrays & records § graphics can be: background pictures, graphical icons, menus § Once data format identified, it is easier to decide on the programming approach to be used. Example: library program which displays the results of a search. Data elements of the screen include search criteria, a list of matches & a means of getting more details about each of the matches

Concept: Implementation: Popular approaches to producing screen designs § simple graphics programs to produce GUI § programming languages VB6, Delphi produce their own screens § DBMS have their own screen design facility. eg: Access [database management system] § File -> Save; located in upper left corner of screen since everyone is used to it being there. User will make fewer errors learning the new software § use colour to select menu item § use common Short-cut keys eg. Ctrl-S to save § scrolling menus for large menus § Everyone one insists on a GUI interface § text-based interfaces (command interfaces) are on the decrease.

Concept: Implementation: Design of Help screens Pt1 Definition: encourage the user to seek assistance immediately when a problem is encountered. Two kinds: Help, I have a problem; Help I need some information. § partial or full help screens: dependent on case Factors of Help screen design: § non-instrusiveness: operates only when requested § flexible sizing: move & resize to see underneath § consistency: appears in the same area of the screen each time it is called. § navigation: user can easily move around the Help menu using browser buttons, tabs or hyperlinks § simplicity: provides basic explanation with links to more detailed explanation § contextual: help is adjusted to the task currently being carried out by the user. § style: always positive & provides actions rather than general statements.

SDD HSC Implementation Page 20 of 43 Concept: Implementation: Design of Help screens Pt2 Different types of Help screens: § context: small assistants that become available within the application to help with a specific problem at a particular moment. Ability to turn it off. § browser: provides a large range of Help strategies, has a Find function. eg. context, index, find § procedural: takes the user sequentially through the steps needed to carry out a process § tutorials: teaching help screens that show the user how to use an application in relative detail. § error messages: should identify the problem in a non-embarrassing way (no beeps or HONKS) § beware of overwhelming user with too much Help

Concept: Implementation: Audience identification Definition: the intended audience for the program eg teenage game, business application. Range of ex- perience. Summary Points: News Article: Y/N § age: huge difference of approach for different age groups § level of expertise: inexperienced users require more assistance but should be able to turn help off by expert users. § language level: technical terms to be avoided. § level of specialization: geographical mapping program can use a technical interface as compared to a simple spreadsheet. § the more general the program, the more help will be needed

Concept: Implementation: Consistency in Approach Definition: consistency allows users to anticipate actions placement eg. printer menu Summary Points: News Article: Y/N § consistency should occur on each of the screens Current Traditional approach: § folders & directories: storage on hard disk § Save command: shown as a disk icon § Printer icon for print commands § letter B used short-cut key for bold format § consistent location of feedback messages § consistent placement of screen elements § consistent background & colours § consistent use of font or typeface

Concept: Implementation: Language Syntax English is a vague language & often phrases have more than 1 meaning. Computing languages can’t use phrases that have more than 1 meaning. Metalanguages were created to describe the rules of a programming languages so phrases can’t mean more than 1 thing. Metalanguages are used to represent the syntax of programming languages. We deal with 2 types: § EBNF & BNF with repetition structures: text based § railroad diagrams: graphics based Both methods carry out the same task but one is text based (like Help in QBasic) and the other is graphics based. See more on metalanguages elsewhere in the summary sheets.

Concept: Implementation: Role of the CPU in the operation of software. Definition: CPU is the heart & brain of a computer system § ALU: arithmetic logical unit: carries out arithmetic and compares numbers <,> or strings § control unit: coordinates the actions of processor § register: memory location within the CPU § direct addressing: addresses a memory location § accumulator: working register, holds data items that are being currently processed § special-purpose: store flags (boolean), to indicate whether a processed instruction results in true/false § program counter: stores the memory location of the next instruction (register) § stack pointer: keep track of the location of the beginning of the stack (part of main memory) § stack: Last In First Out LIFO; stack of plates § clock speed: speed of CPU. 1GHZ = 1000 million electrical impulses per second

Concept: Implementation: Role of CPU continued § fetch execute cycle Subprograms come from: § subprogram specific to main program § library: eg calculation of square root § subprograms that are part of operating system § linker: subprogram’s address in incorporated into the program by this translation system § DLL: dynamic link library: library can be updated with a new one. eg. dll’s in Windows. § Instruction format: conveys a number of pieces of information to the processor. Instruction byte 1, instruction byte 2, instruction byte 3. § source code (3rd level language) is translated to assembly code (2nd generation language)

SDD HSC Implementation Page 21 of 43 Concept: Implementation: Translation methods in software solutions Definition: instructions must be converted from human readable form to machine-readable form. (source code to object code) § compilation: all of the code is translated at once. Will be executed more quickly than interpreted § interpretation: translated line by line § incremental compilation: commonly executed routines are compiled while the program itself is translated by interpreter. Speeds up interpreted side. § translation process: language translator is itself a computer program. Process of translation: source[characters]->lexical analysis[tokens]-> syntactic analysis & type checking[statement blocks]-> code generation[machine code]->object code

Concept: Implementation: Translation continued: lexical analysis[scanning]: spaces, indentations, comment, removed, assigned a token. § token represents key word of language or § identifiers created by programmer eg. SIDE_A identifier tokens stored in a symbol table so translator can keep track of them Syntactic analysis[parsing]: arranges the tokens in a way that allows the computer to understand the logic § parse tree: hierarchical structure. Only one meaning allowed per instruction § error produces a ‘syntax error’ because token cannot be placed on the parse tree. Type checking: detects data types of tokens and detects incompatible operations between differing data types and creating error messages. eg. adding a string to a number.

Concept: Implementation: Translation continued: § code generation: traversing the tree, converts tokens to object code when enough tokens have been collected. § linker: links code to calls to the operating system, to other subprograms and to libraries. § loader: adjusts memory location references so they do not interfere with other parts of the program. Memory locations may vary each time the program is executed. § optimiser: reduces the amount of code so it oc- cupies less memory and to organize the code so that it runs faster

Concept: Implementation: Translation continued: Advantages & Disadvantages of each method: compiler adv: will run faster than interpreted. Hides code from view & one can’t see algorithms used. Smaller than the high-level code that generated it. compiler disadv: run time errors not apparent. Modi- fications means entire program has to be re-compiled, makes testing tedious. interpreter adv: during testing errors become apparent errors can corrected as found. Allows for quick removal of debugging aids. interpreter disadv: runs far more slowly. Code is easily accessible to anyone else. Takes up more storage. incremental compiler: will run faster than those of an interpreter but retains the advantage of identifying errors as they are reached. incremental compiler disadv: not executed as quickly as compiled program. Code is accessible to others which could be illegally used.

Concept: Implementation: Program Development Techniques: Structured Approach complex solution Definition: a hierarchical method involving dividing a complex program into modules. Meaningful names & comments identifies the tasks of each module while meaningful variable names identify the purpose of each variable. One Logical task per subroutine: self-contained sub- routines each carrying out a separate task. § easily tested before joining to main program § isolated & reused as a library routine elsewhere § replaced when the task needs to be altered or updated § easily understood by maintenance programmer § if error occurs, easy to identify module § adaptability to a team approach for development

Concept: Implementation: Program Development Techniques: stubs Definition: are dummy modules to substitute for those sections of the programs that have yet to be written. § allows one to see if main logic is correct § is always simpler than the subroutine it represents § allows the main program to be debugged & tested before modules are added Flags: Boolean variables used to record whether certain events have taken place in a program. § decisions can be made on the state of the flag § useful for the testing phases § value is normally set to ‘false’ initially Example of flag: IF Paid=”” THEN Flag=True ENDIF

SDD HSC Implementation Page 22 of 43 Concept: Implementation: Program Development Techniques: Isolation of Errors Definition: a method of detecting errors. § Tracing the flow of the program § Step through the program manually § debugging tools: breakpoint, watch for variables § once error found, could mean the changing of a condition or the complete rewrite of a module. Debugging output statements: temporary statements placed within code to assist with the process of debugging such as identifying variables or seeing if a module has in fact been activated. eg “Processing the file has been started” or “The stimulus name is animated.avi” § debugging statements are removed.

Concept: Implementation: Program Development Techniques: Elegance of solution Definition: elegant solutions are simpler algorithms & therefore easier to understand, and due to simplicity will form smaller & faster code. Writing for subsequent maintenance: all worthwhile code will need maintenance in the future. To make maintenance easier the program should use modularisation, good internal documentation & process documentation that covers all aspects of program design & testing.

Concept: Implementation: Program Development Techniques: Detecting & correcting errors Definition: a developer need to develop the patience & skill necessary to detect & correct errors within a program. syntax error: errors that have broken the syntax rules of the programming language. Could be typing mistakes, incorrect punctuation & spelling mistakes. § failure to complete grouping such as REPEAT with an UNTIL; IF ELSE ENDIF § today’s compilers / interpreters attempt to give a clue as to the identification of the error eg. datatype mismatch. § use of a reserved word logic errors: errors in the design or the code implementation of a program that result in incorrect output. § desk checking, peer checking, breakpoints, use of debugging output statements aid in detection of errors

Concept: Implementation: Program Development Detecting & correcting errors continued: Peer checking: is having somebody of comparable standard to the programmer check the code or algorithm for errors in logic. Desk checking: where an algorithm is manually worked through with test data items. The results are tabulated on paper and compared with actual outputs. Use of expected output: A test data table is designed to show the expected output from using a range of data input. The expected output is compared to the actual output. If variation occurs, then a check for errors has to take place.

Concept: Implementation: Program Development Detecting & correcting errors continued: run-time errors: errors that are not detected until a program is running. § caused by inability of the computer to perform the intended task. eg. division by zero § control not following the paths as designed § program trying to access inappropriate memory locations. eg. accessing an array location that doesn’t exist. § run on different operating systems

Concept: Implementation: Program Development Use of software debugging tools Breakpoints: are places where the program is made to stop during execution. This allows the programmer to examine the contents of memory locations, variables. resetting variable contents: placing statements within the code that change the values of those variables to known values. The effect of processing can be seen and verifies that the variables are processed correctly. program traces: one follows the order of execution of a program by displaying each line as it is executed. The actual flow of execution is compared with the 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.

SDD HSC Implementation Page 23 of 43 Concept: Implementation: Documentation of a software solution: Overview: documentation forms an integral part of each stage of the system development cycle. § process documentation: value to the developer or maintainer § product documentation: value to the user process diary: a log kept by the programmer of all the steps taken in the development process. It is updated regularly. § allows a new member to become quickly familiar with the process § documents the milestone & pitfalls § allow maintenance programmers to understand the processes that were originally undertaken.

Concept: Implementation: Documentation of a software solution: User documentation: functional description: brief outline of the system requirements & purpose of the system installation guide: specifies minimum hardware & operating system requirements. Written in a non- technical manner. May be users first contact with the program. Illustrations should be used. introductory manual: describes the common functions of the program. § should include tutorial on how to carry out the common functions & how to recover from common errors.

Concept: Implementation: Documentation of a software solution: User documentation: continued: system reference manual: has a complete listing of all the functions of the program. § has a listing of known operational errors & how to recover from them § each function described in detail, inputs / outputs, and any special features. § written in a more formal style & will tend to be more technical. system administrator’s manual: designed to provide the system administrator with a comprehensive description of the program & how it interacts with other elements eg. how to run from a network and known difficulties.

Concept: Implementation: Documentation of a software solution: User documentation: continued: user manual: is the main reference by a user § clearly & logically set out with full index § description of each function and examples § methods of navigation § written in a concise, clear, non-threatening manner § could be a form of online Help § should contain a series of tutorials § trouble shooting guide § use of Balloon text within a GUI eg. cursor over icon produces a text that labels the icon

Concept: Implementation: Documentation of a software solution: Self-documentation of the code § use of intrinsic naming within coding § use of intrinsic characters to break up the coding into segments which is pleasing the human brain § use comments to explain sophisticated chunks of code technical documentation includes: § source code § algorithms § data dictionary § systems documentation The above technical documentation provides the back- bone for future maintenance programmers. § various general applications can be used to produce documentation. § templates should be used to promote consistency between documents

Concept: Implementation: Hardware environment to enable implementation of the software solution. hardware requirements: degree of power needed by computer system. eg. multimedia system requires more power than just word processing. § platform: specific operating/network system § configuration: processor, clock speed & RAM § memory: amount of primary/secondary storage required to install program. § peripherals: additional hardware outside the CPU eg. printers, OCRs, scanner, CD-RW § communications: networks & internet systems that link two or more computers together. minimum configuration: minimum hardware requirements needed to run the software efficiently. § developer should always specify a level of memory § processor speed, specific input/output devices § minimum operating system

SDD HSC Implementation Page 24 of 43 Concept: Implementation: Hardware environment to enable implementation of the software continued: possible additional hardware: specialised peripherals may be needed eg. bar code scanner, optical character recognition. appropriate drivers or extensions: drivers are small programs required to run tasks carried out by a peripherals. Extensions are files that usually are with the operating system & assist in the execution of some programs. § drivers, extensions may need to be part of the installation process but as an option. § eg. older operating systems may not have net- working capability

Concept: Implementation: Emerging technologies Definition: developments in hardware/software can have an effect on the development process. hardware: § has continuously moved to smaller parts, faster processing & bigger memories § digital devices are replacing analogue equipment § artificial intelligence is emerging § data gloves with electronic sensors § voice recognition § natural language reproduction § DVD’s, CD-RW, thumb drives are changing how we

store files

Concept: Implementation: Emerging technologies continued: software: § improvements in operating systems & utilities, more intuitive eg. Norton’s utilities -> communications § compatibility problems with existing software eg. Mac OS 10 won’t run OS 9 products § programming environments should improve § software isn’t as efficient as it used to be due to added functionality & more powerful computers § backward compatibility

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

and to the greatest benefit on the human environment: individual perspective through a global one § a better standard of living § new forms on entertainment & information § ability to perform tasks that were previousl impossible § change of employment (redundancy) § impacts will vary from economic effects through to environmental effects, local, national & global on the development process: almost mandatory to provide online assistance rather than manuals. Printed manuals are being distributed in electronic form rather than on paper.


Bibliography: Fowler’s HSC SDD text Wilson’s HSC SDD text

please turn page.

SDD HSC Implementation Page 25 of 43 Symbol Meaning BNF & EBNF Examples Example: in BNF

Digit:: = 1|2|3 Number:: = <digit> * <digit> Number=1*2,Number=1*3 are legal. Number=3*4 is illegal because it is not a predefined digit or 1 or 2 or 3. Example in EBNF Digit = 1|2|3 Number = <digit> * <digit> Sum={<Number>}-{<Number>} Legal: Sum=(1*2)-(2*3) & Sum=(1*2)(2*2)-(2*3) Illegal: Sum=(1*4)-(2*3) because 4 is not defined. Number is defined as 1or2or3 followed by * and another digit. Sum is defined as a repetition number which could occur once or many time.

<language element> Language element Alternative|Alternative ::= = { } [ ] ( )

Language element defined somewhere else (called non-terminal symbols) These may be § pre-defined – given names § individual characters Terminal symbols-each character in a string of characters is a terminal symbol he vertical bar is placed between alterna-tives. There may be 2 or more of theses. Represents ‘is defined as’ Represents ‘is defined as’ Repeated elements enclosed in braces. The loop may NOT be carried out. Optional elements in square brackets Grouped elements in parentheses

<digit> <letter> display A|B|C meaning A or B or C Word::=<letter><letter><letter> meaning Word is defined as 3 letters Letter=A|B|C|D|E Letter is defined as A or B or C or D or E Word={<letter>} Word is defined as a repetition of the predefined element letter 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 ({<letter>}) The repeated letters are part of the one group.

Concept:


Concept:

Concept:


Diagrams from Wilson’s SDD HSC text.

SDD HSC Testing & Evaluation Page 28 of 43

T esting SoftwareSolutionReporting on the

T esting Process

SDC: Testing & Evaluation

Com parison of the solution and orig inal design speci fications.

Generating relevant test data for com plex solutions.Levels of testing

Uni t or m odule testingProgramSystem

Use of l ive test data to test com plete solution

Larger fi le sizesM ix of transaction types

Response tim esVolume data

Interfaces between modulesCom parison wi th program test data

Benchm arkingQual i ty assurance.

Ensure specs. have measurable outocmes

Clari fy vague termsClari fy ambiguous statementsCalculations accom panied by

exam plesDiagram Pictures used to clari fy

structure

Whi te box testing.Statement coverage testingDecision-condi tion coverage

testingM ul tiple decision-condi tion

coverage testingExhaustive condi tion decision-

condi tion coverage.Black box testing

Boundary analysisEquivalence partitioning

Black box testingWhi te box testing

M odule testing:Ari thmetic errors

Com parison errorsControl log ic errors

Data structure errorsInput, Output errors

Interface errors

Program :Integration testing

T op-down approach Driver m odule

Bottom-up approachFunction testing

Acceptance testing, alpha or beta testing.

System:Perform ance testing

Recovery testingSecurity testingStress testing

Qual i ty Assurance1:Clari ty

correctnessdocumentation

econom yefficiencyflexib il i tygeneral i tyin tegrity

in teroperabi l i tym aintainabi l i ty

Qual i ty Assurance2:m odi fiab i li tym odulari typortabi l i tyre liab il i tyresi lence

reusabi l i tytestabi l i ty

understandabi l i tyuseabi l i tyval id i ty

Documentation of test data & output produced.

Use of CASE toolsCom munication wi th cl ient / users

T est resul tsCom parison wi th orig inal speci fications.

Software test descriptionSoftware description test plan

Software description test report

CASE tools:T est data generator

An oracleFi le com parators

T est management tools

T est resul ts:Problem s m ay cause delays.Efficient use of resources?

M anagement decision.

System Development Cycle:Testing & Evaluation

SDD HSC Testing & Evaluation Page 29 of 43 Concept: Testing & Evaluation:

Compare solution to original design specs. Definition: Summary Points: News Article: Y/N § Compare end product to the original design

specifications. § Good quality, operate reliably, maintenance is

possible. § Interface, input output, procedures meet specs. Example: Compare Quiz end product to design specifications as given by the client (teacher).

Concept: Testing & Evaluation: Generating relevant test data for complex solutions Definition: Summary Points: News Article: Y/N § Can’t test for every possible aspect in complex

Solutions. § Wide range of testing procedures are used. § Whitebox testing Black box testing Example: § XP Operating system § Vista Operating system

Concept: Testing & Evaluation: Levels of testing Definition: Progressive testing, starts at lowest level (module), moves to program level and then tests the environment (system) in which it will operate Summary Points: News Article: Y/N § module testing has mostly taken place in

implementation stage § both black-and-white box testing is used. § Example:

Concept: Testing & Evaluation: Unit or Module testing Definition: Each module is tested to make sure it works as a unit and is free from error. Summary Points: News Article: Y/N § Each module should perform a separate task. § Each module is treated as a stand alone appli-

ation. Test for: § arithmetic errors incorrect calculations

comparison errors: different data types AND instead of OR § Control structure errors due to boundaries, incorrect initialization, or termination • data structure errors: flags, counters • input, output errors: reading writing to files • interface error: parameters passed correctly from one module to another

Concept: Testing & Evaluation: Program testing Definition: ensures that the modules work together and the mainline of the program performs correctly. Parameter passing. Module to Main program relations Summary Points: News Article: Y/N § integration testing: combining the modules § top down: main -> related modules to main § bottom up: test lower level modules first which in turn make up larger modules. § function testing: Users test product & compare against specifications of the user § acceptance testing (custom built): tested where it

will be used § alpha, beta (commercial): first phase under controlled conditions, 2nd phase more open after bugs corrected from alpha phase.

SDD HSC Testing & Evaluation Page 30 of 43 Concept: Testing & Evaluation: System testing Definition: checking the program in environments outside the development environment. Summary Points: News Article: Y/N § ensure that hard/software, data, personnel and procedures work together efficiently, correctly and as intended. Tests focus on: § performance testing: quality of the performance by increasing the transaction load until it fails. § recovery testing: measures the ability to recover itself or the average time for humans to recover it. § security testing: attempts to breach security of the system. Includes computer & manual procedures. § stress testing: create situations where the sysem may fail such as rapid reading, writing to disk. § some tests may overlap with each other

Concept: Testing & Evaluation: Live test data Definition: The real data the program will work with. Summary Points: News Article: Y/N § larger file sizes: difficult to simulate very large files hence, we use real data. § Mix of transaction types: real operations encounter more mixtures of transaction types, some not antici- pated. § response times: times required to complete responses. Limited test data may not give accurate response times. § volume data: amount of data to be processed. One would use pre-existing data. § interfaces between modules: meeting point be- module & main program. Link may be direct or by communication link. Response time may vary.

Concept: Testing & Evaluation: Live test data continued § comparison with program test data: previous test data is compared with live data to make sure actual output matches the expected output. § Benchmarking: comparing a program against a set of established standards. An objective process but results can be interpreted. Usually compare the old system with the new system.

Concept: Testing & Evaluation: Quality Assurance Definition: assures customers of the quality of a prod uct. Must be built into it, can’t be added to an existing product. § clarity: precise & unambiguous instructions § correctness: consistent correct output § documentation: consistent high standard docum. § economy: economical in use of processing needs and external resources. § efficiency: efficient production of output § flexibility: ability to cope with all situations during processing. § generality: eg. word processor interface setup to look like typing on a sheet of paper. § integrity: withstand attacks on its security intentional or not. § interoperability: ability to communicate with pre- existing software eg. operating system

Concept: Quality Assurance continued: § maintainability: ease in which an error in the software can be corrected. § modifiability: ease with which the software can be changed to meet new needs or circumstances. § modularity: able to replace one part without replacing the entire product. § portability: ability to work in different hardware & software combinations. § reliability: a measure of the failure rate of software § resilence: ability to recover from an abnormal situation. § reusability: components can be used in future tasks. § testability: how easily the software can be tested § understandability: quality technical documentation allows the software to be understood. § useability: time for the user required to learn it. § validity: meets the specifications of user

Concept: Testing & Evaluation: White box testing also known as Structural testing Definition: identify and to correct problems emerging during the product’s development. § statement coverage: each statement is executed in a module. § decision condition: test data is used to test each branch within a decision structure within a module § multiple decision-condition: tests all possible combinations of multiple decisions. Nest selections, case § exhaustive condition decision-condition: tests all combinations of true false for each condition Example:

SDD HSC Testing & Evaluation Page 31 of 43 Concept: Testing & Evaluation: Black box testing also known as Functional Testing Definition: identifies that a problem exits within a module. Does NOT identify the source of the problem Summary Points: News Article: Y/N § boundary analysis: choosing test data that are representative of both sides of a boundary. § equivalence partitioning: involves breaking up the data input into groups that have the same properties. eg. database field entitled Family Name. legal characters & illegal characters determined and processed / tested. Example:

Concept: Testing & Evaluation: Documentation of the test data & output produced. Definition: Testing needs to be a carefully controlled and executed process to provide maximum information about the software. Summary Points: News Article: Y/N § software test description: describes the prepara- tions for the tests. § software test plan: describes the test environment, the tests to be performed & provides a time frame. § software test report: provides information about the conduct of the tests & the results. Example:

Concept: Testing & Evaluation: Use of CASE tools Definition: Specific CASE tools have been created for the testing process. Summary Points: News Article: Y/N § test data generator: develops test data items ac- cording to a set of rules. § oracle: predict the output of a program § file comparisons: analyses the results between 2 sets of data,usually from the old system & new system § test management: handles testing processes for multiple tests. § volume tester: simulate use by multiple users. § functional tester: simulate user interaction § simulator: various kinds (machine simulation) § WinRunner, LoadRunner, DataTech [CASE titles]

Concept: Testing & Evaluation: Communication with the client Definition: Custom software, the client more involved as compared to off the shelf. Results need to be frank direct & non-technical language. Summary Points: News Article: Y/N § § § Example:

Concept: Testing & Evaluation: Test Results Definition: problems identified in the testing process. Summary Points: News Article: Y/N § bugs, inconsistencies, lengthy response times or hardware conflicts. § problems may cause delays. § limitations of the program may be issues § 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. Example:

Concept: Testing & Evaluation: Comparison with the original design Definition: Each specification to be checked. If all working then all Ok. If not, needs to be brought up to standard and an explanation of the shortcomings. Summary Points: News Article: Y/N § efficient use of resources? § management decision to wait for full product. § Example:

SDD HSC Testing & Evaluation Page 32 of 43 Concept: Definition: Summary Points: News Article: Y/N § § § Example:






SDD HSC Maintenance Page 33 of 43

M odi fication of Code due to Changed Requirements

Documentation ofChangesSDC: Maintenance

of Software Solutions

Changing user requi rem entsUpgrading user interface

Changes in data to be processedChanged m ethods of data processing

Intro. of new hardware / softwareChanging of organisational focus

Changes in gov't requi rementsPoorly im plemented code

Identi fication of the reasons for changeLocation of section to be a l teredDetermin ing changes to be madeImplementing & testing a solution

Configuration m anagem entSource code, m acro & scrip t

documentationM odi fication of associated hard copy

documentation & onl ine helpUse of CASE tools to m oni tor changes &

versions

Configuration m anagem ent:M anagement of versions & releases

of software.System bui ld ing

Control & m anagem ent of system change

Configuration p lanning

Needs

T echnicalOrganisation

UserLegislation

M odi fy:Rem ove a bug (patch).Changes in input data.

Change operation.M eet new requi rem ents.

Improve efficiency.Hard/software changes

Govt requi rementsCurrency of Product

Improved functional i ty

System Development Cycle:Maintenance

M aintenance types:Corrective M aintenanceAdaptive Maintenance

Improvement M aintenance

SDD HSC Maintenance Page 34 of 43 Concept: Maintenance: Changing user requirements Maintenance: upgrading or repair of a program. Definition: User becomes more familiar with the application & needs to perform further tasks. Their needs evolve & grow. Summary Points: § Maintenance costs are over half of the total system development cycle. § Much is needed from software today and more will be required tomorrow. Software needs to be able to be upgraded with as little disruption as possible to the user. Example:

Concept: Maintenance: Upgrading user Interface Definition: user interface often contains aspects that would benefit from redesign. Long term use may bring to light problems Summary Points: News Article: Y/N § § § Example: design of menu & key combinations used for shortcuts.

Concept: Maintenance: Changes in the data to be processed Definition: Changes in the form of the data to be processed. Summary Points: News Article: Y/N § Millennium bug: § Australian telephone numbers increased to 8 digits § ABN number required on all invoices within Austr. § Banks had to modify their software to utilize tax file numbers when introduced by legislation. Example:

Concept: Maintenance: Introduction of new hardware/software Definition: Summary Points: News Article: Y/N § Long last software has to undergo modification to make use of new technology and to take advantage of what the new technology has to offer. § § Example: Introduction of laser printers, scanners & new operating systems. * USB Ports

Concept: Maintenance: Changing of organisational focus. Definition: a business continually goes through a process of evolution Summary Points: News Article: Y/N § often business expansion is similar to the core business and the software can be adapted to the new acquisitions. § § Example: P&O evolved from just a shipping company to running cruise liners, owning resorts, cleaning company.

Concept: Maintenance: Changes in government requirements Definition: legislation changes which in turn reflects social, political & economic circumstances. Summary Points: News Article: Y/N § ABN number § tax file number § display costs of ATM transaction § track use of particular chemicals Example: chemists have to enter who purchases certain tablets eg. sudafed

SDD HSC Maintenance Page 35 of 43 Concept: Maintenance: Poorly implemented code Definition: Older software may not be as structured as it should be, hence, reducing efficiency. Mainten- ance of code is preferred over a patch. Summary Points: News Article: Y/N § § § Example:

Concept: Maintenance: Identification of the reasons for change in code, macros & scripts Definition: Maintenance is not about a quick fix but about creating a lasting solution. § identify the needs of the user § identify the needs of management / govt § full documentation on the problem, solution is needed, particularly when more than likely a different programmer will carry out the maintenance. § as time passes, technology becomes outdated § technical needs § legislative needs § user needs § organisational needs Usual Problem-solving strategy: define the problem->design a solution->test and implement the solution

Concept: Maintenance: Reasons for changing code § bug fixes (patch) § changes in input data (6 to 8 digits) § change in operation § meet new requirements: changes to govt regulations or organisational structure. eg. GST § improve efficiency § hard/software changes eg: printing to a laser § govt regulations § currency of product: bring code up to date. eg. move from assembly language to event-driven language § improved functionality: expand the original solution. eg. add module for greater choice of fonts.

Concept: Maintenance: Location of section to be altered Definition: where alterations to coding will take place Summary Points: News Article: Y/N § can be new modules: easier to do because no pre-existing structures have to be linked eg. parameter passing § modification of existing code requires understanding of specific module and impacts upon other modules. § thorough understanding of original code and thorough understanding of original documentation is usually needed. Example:

Concept: Maintenance: Determining changes to be made Definition: The cost & impact of changes have to be assessed. § priority: urgent if business can’t operate § extent: number of changes to be made and level of difficulty eg: screen design adjustment vs adding a new function § personnel: who does the changes, in-house or will it be outsourced? § skills & expertise: the skills needed to make the changes at time of maintenance. § changes could have impact on other parts of the program

Concept: Maintenance: Implementing & testing a solution Definition: testing of changes should be just as rigorous as full implementation of original program Summary Points: News Article: Y/N § changes probably need to be carried out in the same environment as originally created eg TUSIL § use test data for revised specifications § minimise downtime § may involve retraining of users Example:

SDD HSC Maintenance Page 36 of 43 Concept: Maintenance: Configuration management Definition: management of software resources. configuration planning, control & management of system change, system building, management of versions & releases of software. § configuration planning is where documents needed for further development are identified & placed under configuration control. § when software is modified so must be the respective documents. § change control: software changes are done in a controlled & predictable way § modification to original code needs to be documented. Example: § Word tracks changes in a document

Concept: Maintenance: Source code, macro & script documentation Definition: should follow the rules covered earlier in the course eg. intrinsic documentation Summary Points: News Article: Y/N § code: high-level language § macros: prerecorded automated tasks § script: commands carried out without user interaction eg. JavaScript § descriptions of the process & design documentation assists in the maintenance process.

Concept: Maintenance: Modification of associated hard copy documentation & online help Definition: any changes in software has to be re- flected in documentation that goes with the product. Summary Points: News Article: Y/N § updating & distributing hard copy documentation is quite cumbersome when compared to online help § online documents can be easily downloaded from the Internet or from a CD § Example:

Concept: Maintenance: Use of CASE tools to monitor changes & versions Definition: Summary Points: News Article: Y/N § a number of configuration management tools exist. § Merant’s PVCS is one specific title § Example:

Concept: Maintenance: Definition: Summary Points: News Article: Y/N § § § Example:

Concept: Maintenance: Definition: Summary Points: News Article: Y/N § § § Example:

SDD HSC OPTION: Evolution Programming Languages Page 37 of 43

Evolution of Program ming Languages

First Generation (machine) language:Coded in b inary dig i ts.

Hexidecimal , octal developed to reduce errors in coding.

M nemonics.Processor-dependent.

Can reside only in 1 location which caused 2nd generation

2nd-Generation sym boic language:Uses sym bol ic addresses.

Assembler takes care of new memory location.

Notes in coding al lowed.M ay include a debugger.

Assembly language can run faster.Developing interfaces to devices,

creating ROM m odules, or m icroporcessor control led m achines ge.

com pact disc palyer.Not easy to learn.

3rd Generation languages:Great leap forward.

Instructions closer to sym bol ic language used in science or business.

Independent of com puter system .As technology im proved each l ine could

be in terpreted.FORTRAN: science, maths

COBOL: businessT echnology l im i ted com pi lation.

M anufacturers developed thei r own versions, hence, l im i ting portabi l ity.

4th Generation language:WHAT the program has to do rather than

HOW it is to be done.Com puter power increased, cost decreased.Attempts to make interaction wi th humans

easier.Characterised by sim ilari ty to speech eg.

Logo, Hypertalk.Logo is a chi ld of LISP.

LISP si ts on the border of 4th & 5th generation languages.

5th Generation Language:Uses arti ficia l in tel l igence m ethods for problem

solving.Uses logic programm ing... based on the princip les

of formal log ic.PROLOG: resolution -> deduction

Characteristics

Object Oriented Language:Constructed from objects & messages.Black box: sends & receives messages.

We have no interest in how i t works.An object m ay not be understood, but can stil l

be used effective ly.OOP are concerned wi th objects.

Objects are responsible for thei r own actions.Objects respond to requests from cl ients via

m essages.OOP: coding (function) & data kept together in

an object. eg. student m arks program.An object only needs to be manipulated, we

don't need to see inside the object, hence, the 'b lack box.'

Class -> subclass inheri ts properties from parent.

M ethods: how they deal wi th a message.Re-use code through m anipulation and adding

new characteristics.Saves time, money & effort.

If an object is deleted, connections to the deleted object have to be redi rected correctly.

Encapsulation:Group subprograms &

re lated data ei ther individually or in groups of

com ponents that are re lated.Subprogram s.

Library routines,Sim pli fying com ms between

objects.

Polymorphism:For effective maintenance or extension of a program only the addi tion of a subclass is

requi red.Vehicle -> car1, car2, car3,

car4, car5, car6.Subclass (car) inheri ts form

the parent class, vehicleControl program doesn't have

to be modi fied.

Classes:A specia l abstract data type.

Refers to the properties of that data i tem .

Parent -> Class -> subclass

Inheri tance:In a hei rarchial structure is the abi l i ty

of the cl ient to have al l the characteristics of the parent & to gain

new ones.Allows us to re-use code.

M ethods:Defines what the object can do. eg. car

turns right or le ft.An object encapsulates the properties

& the a lgori thm s that are used to process them via messages.

M essage:Paream eters,

Operation,Destination

Abstraction:A problem can be viewed in fam il iar

term s eg. objects.Allows us to sim pli fy the programm ing

process.Data Abstraction: looks at data in

fami l iar term s such as characters & num bers.

Process abstraction: sequence of instructions that have a clearly

defined and l im i ted purpose.

Discription & Hidtory of Langauges

Logic Paradigm (model )

C++:ALGOL60 -> C(1972) -> C

v.2(1989 C++ is a hybrid language.

Flagship of OOP methodology.Backward compataib le with C

Com pi led language -> object fi le -> l inked to requried libraries ->

coverted into executable.Com pi lers faster than

InterpretersDisadv. inherited m any faul ts

of C.Perceived to be too large &

com plex a language.

Java:Sun Microsystem s 1990.

Orig inal ly for sm al l consum er e lectronic devices.

Needed to be simple & extremely re l iab le.

Portabi l i ty.Popular wi th web developers &

an a l ternative to Microsoft.Java vi rtual machine a l lows

portabi l i ty.Disadv: speed, can't be

com piled in advance but as the program is being executed.

Delphi :Derived from Pascal .

Development tool for Windows with GUI.

Object oriented Pascal .An event occurs from user

action.L ibraries: classes of objects ->

windows, buttons, custom tools. S im i lar to VB6.

Can access local & network databases.

Cal led non-procedural , declarative or logic.

Associated wi th arti ficia l in te ll igence.Focus: abil i ty to learn, to process

knowledge, to m ake inferences & to gain knowledge.

Statements not processed in a precise order nor rapidly.

Deta i led statem ents describe what is true about a desi red result.

Independence of log ic & contro l .Logic: what is to be solved

Control : how it should be solved.3 statem ents: facts, queries & ru les.

User supplies a goal : so lved by resolution or backward chain ing and / or

forward chaing

Goals:Achieved when a group of

facts from the database are m atched. (Prove som ething is

true).

In ference Engine:Processing part of an expert

system. Provides the reasoning abi l i ty

to m ake conclusions.

Backward Chain ing:Problem solving procedure.

Starts wi th a statem ent & a set of ru les leading to the statement

& then works backward, m atching ru les with the

in formation from a database of facts unti l the statem ent can be

proved e i ther right or wrong.Works best on a smal l number

of resul ts.Prem ise: a source can be found without the need to obta in a ll the

data.

Forward Chaining:Starts wi th a set of ru les & a

database of facts & works to a conclusion based on facts that

m atch a l l the premises.Works where ther are a large num ber of correct resul ts.

Expert System Shel ls

Program designed to act l ike an expert.Knowledge-based systems.

Designed to deal wi th uncertainty.

Knowledge Base:Database bui lt up by a knowledge

engineer.Includes sim ple facts, ru les that describe

re lationships & possible methods.Database needs to grow as i t learns new

facts.

Inference Engine:Appl ies the knowledge to the data to arrive

at some conclusion.Deduces som ething from the data.

User Interface:Provides sm ooth & clear comm unication

between the user & the system.It should give insight as to how the

problem solving process is carried out.

Pro log:Program ming in Logic.

Evolved since early 70 's.Program mer needs to provide only the ru les & not worry about the sequence.

Functional Program ming

Program which consists enti rely of functions.

Side effects,Recursion.No assignment statements.

No g lobal variables.Ensures no side effects.

No loops but uses recursion (a process of defin ing i tse l f).

Greatly improves m odulari ty.Currently inefficient & not su itable for som e appl ications. Run more slowly &

not sui table for general -purpose program ming.

Could be the way of the future.

Heuristics:Finding a set of rules that

finds satisfactory solutions to a speci fic problem.

Enables the creation of many d i fferent so lutions.

Com mon LISP:Principal language for arti ficia l

in te l l igence & 2nd o ldest general -purpose langauge.

Run in an in teractive envi ronm ent.Interpreted language.

Parent of LOGO.

APL: a program ming language.Developed to concisely express

a lgori thm s in m athematics which in turn could be translated into

conventional programm ing languages.Can be extremely d i fficu lt to read but

seen as i ts strength. S ingle l ine of code can do a large

num ber of computations.No notion of Main Program .

Precedence is right to le ft for form ulas.

Smal l dedicated group of fo l lowers.

Evolution of Programming

Languages Option


Concept: Correlation between Language generation & hardware generation Definition: Summary Points: § Correlations can be drawn between the developing generations of hardware & programming languages. § Vacuum tube based machines didn’t provide sufficient power to enable higher-level languages to evolve. The transistor allowed the assembler to come into being (Fortran & Cobol) § Processing power has allowed languages to become more intelligent, user friendly & processor independent. Example:

Concept: Reasons for development of programming languages Definition: Summary Points: § Repetitive standard programming tasks § Desire to solve different types of problems § Expansion to meet different needs as new hardware & peripherals (technology) have emerged § Greater productivity

1990’s – Artificial intelligence, Neural networks, Quantum computing

5th

1980’s-1990’s Operating system independent. User-friendly, easy to use for non-programmers. Portable

4th

1960’s-1980’s Considered high-level languages. Introduction of compilers in addition to being machine independent

3rd

Late 1950’s Assembly languages. Machine independent

2nd

Early 1950’s Machine languages. Machine dependent

1st

Characteristics Features Generation

1990’s Pentium processor is released, networks become the norm

6th

1980’s – 1990 First WAN is established, parallel processing introduced, computers become portable (desktops)

5th

1970’s - 1980 First microprocessor is designed. CRAY supercomputer is designed.

4th

1960’s Integrated circuits replace transistors

3rd

1950’s – 1960’s Transistors replace vacuum tubes

2nd

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

1st

Characteristics Features Generation


eat(lion, dog). eat(dog,cat). eat(cat,bird). eat(bird,spider). eat(spider,fly).

Concept: Imperative Programming Definition: Commands are performed to affect the state of the program. Data represents the state. Processing & data separated. Summary Points: News Article: Y/N § data sent to CPU for processing & stored in memory § uses main control structures § creates variables for storage § does the same old thing but faster due to advances in hardware technology § distinct beginning & end § re-usable code is NOT an integral part of the imperative language (but desirable). Example: § C § Visual Basic, QBasic

Concept: Example of Imperative Programming C void find (int sum) { int i, current, total; for (i = 1; i < sum; i++) { total = 0; current = i; do { total = total + current; current = current + 1; } while (total < sum); if (total == sum) print (i, current - 1); } }

Concept: Adv/Disadv. Imperative programming § easy to understand since it corresponds with every day life eg. cooking, giving directions § not too many tricky concepts § straight-forward to implement efficiently on computer hardware § doesn’t fit all real life situations eg. medical analy sis using intuition, communication with people Disadvantages § runs commands that change (side-effect) the values of variables until the desired output is achieved. § can only be perceived by understanding all of the variables that are used by all commands that changes the variables (can be hard to debug) § Reasoning about imperative programs can be hard and debugging and maintenance can be difficult.

Concept: Logic Programming Definition: also known as non-procedural, declarative. Associated with artificial intelligence Summary Points: § In the other paradigms control flow is explicit via conditional statements, loops and function calls, etc. § In contrast, logic programming uses the resolution process with its implicit backtracking so programs are easier to write, understand and maintain. § The downside is that implementing backtracking is costly in time and space compared to implementation approaches for other paradigms. § Example:

Concept: Prolog eat(lion,bird):-et(lion,X), at(X,bird)

Concept: Expert Systems § Performs functions that normally would be performed by a human expert in that field. § Do not reach definite conclusions but weigh up the evidence & present possible conclusions. § uses facts & rules, probabilities § uses heuristics – rule of thumb that are generally accepted as true within a specialist area § conclusions reported as probabilities § Understands how a human expert reasons § Stored in a knowledge base § Expert system shells provide the framework § It cannot learn new information

eat(lion,dog) eat(dog,bird)

eat(cat,bird) eat(dog,Y) eat(Y,bird)

eat(dog,cat)

eat(lion,bird)

eat(lion,X) eat(X,bird)

SDD HSC OPTION: Evolution Programming Languages Page 40 of 43 Concept: Expert System Hugin Lite Probability Result

Concept: Prolog Coding parent(marta,joe). parent(marta,jules). parent(marta,lil). parent(nick,jules). parent(nick,joe). mother(Mother,Child) :- female(Mother), parent(Mother,Child). father(Father,Child) :- male(Father), parent(Father,Child). grandparent(Grandparent, Grandchild) :- parent(Grandparent, X),

parent(X, Grandchild). ?- parent(tezza,marta).

Concept: Functional Programming Definition: A program that consists entirely of functions eg. Dr Scheme Summary Points: § Functional programming tries to resolve problems with variables by making the whole program a function from some input to some output. § no assignment statements. Variables don’t change § all you need to understand is how functions call each other. § no need for a programmer to understand many different commands to work out what the program will do. § enforces use of modules (re-use of code) § not widely used nor accepted § 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: Functional code examples (define (square num) (* num num) ) (define (factorial n) (if (eq? n 0) 1 (* n(factorial (- n 1))) ) ) ; fibonacci function in which fib(1) = 1 and fib(2) = 2 (define (fib n) (if (eq? n 1) 1 (if (eq? n 2) 1 (+ (fib (- n 1)) (fib(- n 2))) ) ) )

Concept: Functional Language use Lists § In functional languages, the list is the most

important data structure. A list can consist of zero or more elements, list can also be nested

§ (list 3 4 56) a list of three numbers § (list “a” “j” “o” “p”) a list of four characters § (list ) an empty list § (list (list 2 3) (list 5 6)) a list within a list ; type this (member 3 (list 3 4 56)) ; example of using a list in DrSchem (define (member e l) (if (empty? l) #f (if (eq? e (first l)) #t (member e (rest l)) ) ) )

Sick Dry

Loses

Loses

DrySick

Harv

Treat

Cost

SDD HSC OPTION: Evolution Programming Languages Page 41 of 43 Concept: Programmer’s Productivity Definition: the choice of a paradigm may have impact upon the productivity of the programmer. Summary Points: Learning Curve: Learning curves of new paradigms are steep. OOP is now widely accepted & learned early. § functional is NOT widely accepted § logic programming in NOT widely accepted § ‘marketing’ strategies need to be put into place to gain faster acceptance. § learning 1 language can carry over to another § many languages require more expertise than others Speed of code generation: Languages that increase the speed of code generation increases productivity. § machine language is fastest but longest to develop § OOP more efficient but slower to execute § Imperative languages fastest but due to tech. § Others reduce development time.

Concept: Programmer’s Productivity Effect on maintenance: languages (OOP, functional) that enforce writing in modules have positive impact upon maintenance. § modules already tested, can be re-used, blackbox § easy to locate the coding to be modified within the modules for maintenance approach to testing: languages (OOP, functional) that enforce creation of modules increases productivity when testing. § modules are independent & have already been tested. Don’t have to be re-tested if unchanged § modules inherit in OOP. Inherited modules do not need or little testing. § amount of testing is dramatically reduced, hence, increasing the productivity especially if the modules are re-used.

Concept: Programmer’s Productivity Efficiency of coded solutions: Imperative languages are fastest due to advances in hardware technology but not due to advances in software technology. § imperative languages more apt for technology other languages, although slower, may have less development time

Concept: You may want to add object oriented here. Definition: Summary Points: News Article: Y/N § § § Example:


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.

SDD HSC OPTION: Evolution Programming Languages Page 42 of 43 Concept: Definition: Summary Points: News Article: Y/N § § § Example:







Technology

Sdd HSC Summary