Embed
Email

Human Computer Interaction

Document Sample

Shared by: xiang
Categories
Tags
Stats
views:
0
posted:
11/5/2011
language:
English
pages:
24
2008









YEAR

Quality Assurance

Introduction to Part I

SOFTENG 254









Part I - Lecture 1

The University of Auckland | New Zealand









1

Christof Lutteroth

• Just became a permanent lecturer

2008









YEAR

• From Berlin, Germany

• Two years ago this was the first lecture given by me

SOFTENG 254









(you can watch the old lectures on video)

• My research interests: model-based SE, generative

programming, DBMS, e-commerce, …

• Contact details:

lutteroth@cs.auckland.ac.nz

The University of Auckland | New Zealand









Phone 373-7599 84478

Office: 303 - 494 (4th level CompSci building)



• If you have questions, come to my office at any time



2

2008









YEAR

SOFTENG 254









Introduction to Part I

The University of Auckland | New Zealand









Quality means doing it right

when no one is looking

(Henry Ford)





3

Why not just Dynamic

Detection of Defects?

• Second half mostly about dynamic detection of

2008









YEAR

defects

• Can be time consuming, costly, complicated…but is

SOFTENG 254









necessary!!!

• Requires a (partially) running system already.

What if we don’t have it yet?

• Usually in the implementation stage of a project.

What if the defect has its origin in the specification

The University of Auckland | New Zealand









or design?

• What if our test cases contain defects?



How can we avoid defects

in the first place?

4

Avoiding Defects:

Best Practices

• Avoiding the mistakes that cause defects by “doing

2008









YEAR

the right thing”

– Software development processes:

SOFTENG 254









how to undertake a software project

– Software configuration management:

how to keep track of all the artifacts and changes

– Design & coding guidelines:

how to avoid programming mistakes

The University of Auckland | New Zealand









• Learn from other’s experience & mistakes

(not as effective as learning from own mistakes, but

saves time )

• But: what works for others does not necessarily work

for you (nothing can replace your own experience)

5

Avoiding Defects:

Tool Support

• Avoiding defects by using the right tools

2008









YEAR

• Humans are necessary for creative, intelligent tasks

• Tools can support such tasks

SOFTENG 254









– Increase productivity with useful functionality

– Guide the developer (e.g. context help)

– Avoid defects, e.g. with robust user interfaces

• But humans are not always necessary for highly

The University of Auckland | New Zealand









repetitive, routine work

• Tools can automate such tasks

– Increase productivity; more time for creative work

– Avoid defects introduced by the human factor



6

Static Detection of Defects



• If we cannot avoid defects, detect them as early as

2008









YEAR

possible

• “Static” means before runtime

SOFTENG 254









• Most compilers detect many type errors (type

systems), other tools detect even more errors

• The more specification we give, the more we can

verify; formal specification languages (e.g. Z, Alloy,

The University of Auckland | New Zealand









Hoare Calculus)

• Sad result from theory:

some errors cannot be detected statically!!!

• But we can be “conservative”:

prohibit even code that might be an error

7

2008









YEAR

SOFTENG 254









CASE Tools

The University of Auckland | New Zealand









First we shape our tools and

then our tools shape us

(Marshall McLuhan)





8

CASE Tools

Computer Aided Software Engineering

2008









• IDEs (e.g. Eclipse, Visual Studio)

YEAR

SOFTENG 254









• Build tools (e.g. ant, make)

• Documentation tools (JavaDoc)

• GUI builders (e.g. VE for Eclipse, VS Designer)

• Version control systems (Subversion, CVS)

The University of Auckland | New Zealand









• Modeling tools (Together, ArgoUML, Rational Rose)

• Generators (JET, ANTLR)

• Reverse engineering tools

• …



9

Integrated Development

Environments (IDEs)

• Also called “workbenches”

2008









YEAR

• Provide a common, extensible user interface for

different CASE tools

SOFTENG 254









• Common UI: all tools can be invoked from and display

their output in the IDE

• Extensible: plug-in architecture

– Plug-ins: program components that can be “plugged“

into a system

The University of Auckland | New Zealand









– Usually sit in their own UI panel

• IDE usually provides common resources to all

integrated tools, e.g. access to source code, internal

models, ...



10

SOFTENG 254

The University of Auckland | New Zealand









YEAR

2008



Environments (IDEs)

Integrated Development









11

SOFTENG 254

The University of Auckland | New Zealand









YEAR

2008

GUI Builders









12

Version Control Systems

• Technology to manage changes that several

2008









YEAR

developers do on a common repository

• Changes create new version of the changed files

SOFTENG 254









• Old versions are always accessible

Developers



Working

The University of Auckland | New Zealand









Copy Repository



Working Version 5

Copy Version 4

Version 3

Version 2

Working

Version 1

Copy 13

SOFTENG 254

The University of Auckland | New Zealand









YEAR

2008



Example: Subversion

Version Control Systems









14

Build Tools

Example: make

2008









all: calc

YEAR

Dependency graph

SOFTENG 254









calc: main.o math.o

g++ main.o math.o -o calc calc



main.o: main.cpp

g++ -c main.cpp

The University of Auckland | New Zealand









main.o math.o



math.o: math.cpp math.h

g++ -c math.cpp

main.cpp math.cpp math.h

clean:

rm *.o

15

Documentation Tools

Example: JavaDoc

public class Stack {

2008









/**

YEAR

* Pushes an item on to

* the top of this stack.

* @param item the item to be pushed.

SOFTENG 254









*/

public void push(Objec item){

this.elements.add(item);}

/**

* Removes the object at the top

* of this stack and returns that

The University of Auckland | New Zealand









* object.

* @return The object at the top

* of this stack.

* @exception NoSuchElementException

* if this stack is empty.

*/

public Object pop()

throws NoSuchElementException {

// ...

16

} }

SOFTENG 254

The University of Auckland | New Zealand









YEAR

2008

Modeling tools









17

Generators

• There are “routine” development tasks: creating an

2008









YEAR

artefact Y according to a specification X

• E.g. interfaces (DB, GUI), some design patterns and

SOFTENG 254









standard functionality

• Idea: automate tasks with parameterized generators

• Usually transformation of high-level constructs to

lower-level ones

The University of Auckland | New Zealand









• Advantages: save time and avoid mistakes by reducing

human involvement where it is unnecessary





Input

Generator Output

(Parameter)

18

Generators

Generation of a web UI

2008







JSP

YEAR

JSP

Generator JSP

SOFTENG 254









JSP



Generation of Java classes

Class

Class

The University of Auckland | New Zealand









Generator Class

Class



Generation of language parsers

Source code

Language

Generator for parser

grammar

19

Reverse Engineering Tools

• Recover information from a finished system

2008









YEAR

• E.g. construction plan, data model, all kinds of documentation

• Important for maintenance of legacy systems

SOFTENG 254









• Many methods, e.g.

– Static analysis: just examine the code

– Dynamic analysis: look at program behaviour at runtime

– Black box analysis: only look at outputs

– White box analysis: also look at internals

The University of Auckland | New Zealand









Data

Source Model

Code Documen-

Program RE Tool tation

Architecture Specifi-

Diagram cation

20

Reverse Engineering Tools

Source code recovery

2008









Source Source

YEAR

Executable code Source code

Tool

SOFTENG 254









application code



Data model recovery

Class

Class

Class Tool

The University of Auckland | New Zealand









Class



Exploration of runtime behaviour





Execution trace

Executable Tool e.g. call graph

application

21

SOFTENG 254

The University of Auckland | New Zealand









YEAR

2008









Summary









22

Today’s summary

• Dynamic detection of defects (e.g. testing,

2008









YEAR

debugging) is necessary, but not enough

• Static checking (e.g. with type systems) can detect

SOFTENG 254









some defects before runtime

• We can avoid defects by following best practices of

software development and using CASE tools

• CASE tools support the developer in performing

The University of Auckland | New Zealand









creative tasks and can automate routine tasks



Tomorrow:

No tutorial

No lab

23

Quiz

1. How can defects be avoided?

2008









YEAR

Name two examples.

SOFTENG 254









2. What tools exist for supporting software

development?

Name 5 of the CASE tool categories.

The University of Auckland | New Zealand









24



Related docs
Other docs by xiang
The Parable of the Rich Fool
Views: 23  |  Downloads: 0
14838-Nat.Equest Summer 08-2
Views: 7  |  Downloads: 0
kompendium_februar_01
Views: 1  |  Downloads: 0
Antimikrobielle Wirkung ausgewhl
Views: 2  |  Downloads: 0
Vietnamese BULLETIN vietnamien
Views: 1  |  Downloads: 0
Information Retrieval Models and
Views: 19  |  Downloads: 0
Download our Menu - Aveda Institutes
Views: 2  |  Downloads: 0
Journ茅e mondiale de l'hydrograph
Views: 2  |  Downloads: 0
SJSAS
Views: 0  |  Downloads: 0
By registering with docstoc.com you agree to our
privacy policy

You are almost ready to download!

You are almost ready to download!