Well- -behaved objects behaved objects Well Improving your coding - - PowerPoint PPT Presentation

▶
well behaved objects behaved objects well
SMART_READER_LITE
LIVE PREVIEW

Well- -behaved objects behaved objects Well Improving your coding - - PowerPoint PPT Presentation

May 03, 2023 29 likes •515 views

Well- -behaved objects behaved objects Well Improving your coding skills 1.0 Main concepts to be covered Main concepts to be covered Testing Debugging Test automation Writing for maintainability 10/11/2005 Lecture 6:

slide-1
SLIDE 1

Well Well-

  • behaved objects

behaved objects

Improving your coding skills

1.0

slide-2
SLIDE 2

10/11/2005 Lecture 6: Wel-behaved Objects 2

Main concepts to be covered Main concepts to be covered

  • Testing
  • Debugging
  • Test automation
  • Writing for maintainability
slide-3
SLIDE 3

10/11/2005 Lecture 6: Wel-behaved Objects 3

We have to deal with errors We have to deal with errors

  • Early errors are usually syntax errors.
  • The compiler will spot these.
  • Later errors are usually logic errors.
  • The compiler cannot help with these.
  • Also known as bugs.
  • Some logical errors have no immediately
  • bvious manifestation.
  • Commercial software is rarely error free.
slide-4
SLIDE 4

10/11/2005 Lecture 6: Wel-behaved Objects 4

Prevention Prevention vs vs Detection Detection

(Developer (Developer vs vs Maintainer) Maintainer)

  • We can lessen the likelihood of errors.
  • Use software engineering techniques, like

encapsulation.

  • We can improve the chances of detection.
  • Use software engineering practices, like

modularization and documentation.

  • We can develop detection skills.
slide-5
SLIDE 5

10/11/2005 Lecture 6: Wel-behaved Objects 5

Testing and debugging Testing and debugging

  • These are crucial skills.
  • Testing searches for the presence of errors.
  • Debugging searches for the source of errors.
  • The manifestation of an error may well occur

some ‘distance’ from its source.

slide-6
SLIDE 6

10/11/2005 Lecture 6: Wel-behaved Objects 6

Testing and debugging Testing and debugging techniques techniques

  • Unit testing (within BlueJ)
  • Test automation
  • Manual walkthroughs
  • Print statements
  • Debuggers
slide-7
SLIDE 7

10/11/2005 Lecture 6: Wel-behaved Objects 7

Unit testing Unit testing

  • Each unit of an application may be tested.
  • Method, class, module (package in Java).
  • Can (should) be done during development.
  • Finding and fixing early lowers development

costs (e.g. programmer time).

  • A test suite is built up.
slide-8
SLIDE 8

10/11/2005 Lecture 6: Wel-behaved Objects 8

Testing fundamentals Testing fundamentals

  • Understand what the unit should do – its

contract.

  • You will be looking for violations.
  • Use positive tests and negative tests.
  • Test boundaries.
  • Zero, One, Full.
  • Search an empty collection.
  • Add to a full collection.
slide-9
SLIDE 9

10/11/2005 Lecture 6: Wel-behaved Objects 9

Unit testing within BlueJ Unit testing within BlueJ

  • Objects of individual classes can be created.
  • Individual methods can be invoked.
  • Inspectors provide an up-to-date view of an
  • bject’s state.
  • Explore through the diary-prototype project.
slide-10
SLIDE 10

10/11/2005 Lecture 6: Wel-behaved Objects 10

Test automation Test automation

  • Good testing is a creative process, but ...
  • ... thorough testing is time consuming and

repetitive.

  • Regression testing involves re-running tests.
  • Use of a test rig or test harness can relieve

some of the burden.

  • Classes are written to perform the testing.
  • Creativity focused in creating these.
slide-11
SLIDE 11

10/11/2005 Lecture 6: Wel-behaved Objects 11

Test automation Test automation

  • Explore through the diary-testing project.
  • Human analysis of the results still required.
  • Explore fuller automation through the

diary-test-automation project.

  • Intervention only required if a failure is

reported.

slide-12
SLIDE 12

10/11/2005 Lecture 6: Wel-behaved Objects 12

Modularization and interfaces Modularization and interfaces

  • Applications often consist of different

modules.

  • E.g. so that different teams can work on them.
  • The interface between modules must be

clearly specified.

  • Supports independent concurrent development.
  • Increases the likelihood of successful

integration.

slide-13
SLIDE 13

10/11/2005 Lecture 6: Wel-behaved Objects 13

Modularization in a calculator Modularization in a calculator

  • Each module does not need to know

implementation details of the other.

  • User controls could be a GUI or a

hardware device.

  • Logic could be hardware or software.
slide-14
SLIDE 14

10/11/2005 Lecture 6: Wel-behaved Objects 14

Method signatures as an Method signatures as an interface interface

// Return the value to be displayed. public int getDisplayValue(); // Call when a digit button is pressed. public void numberPressed(int number); // Call when a plus operator is pressed. public void plus(); // Call when a minus operator is pressed. public void minus(); // Call to complete a calculation. public void equals(); // Call to reset the calculator. public void clear();

slide-15
SLIDE 15

10/11/2005 Lecture 6: Wel-behaved Objects 15

Debugging Debugging

  • It is important to develop code-reading

skills.

  • Debugging will often be performed on others’

code.

  • Techniques and tools exist to support the

debugging process.

  • Explore through the calculator-engine

project.

slide-16
SLIDE 16

10/11/2005 Lecture 6: Wel-behaved Objects 16

Manual walkthroughs Manual walkthroughs

  • Relatively underused.
  • A low-tech approach.
  • More powerful than appreciated.
  • Get away from the computer!
  • ‘Run’ a program by hand.
  • High-level (Step) or low-level (Step into)

views.

slide-17
SLIDE 17

10/11/2005 Lecture 6: Wel-behaved Objects 17

Tabulating object state Tabulating object state

  • An object’s behavior is usually determined

by its state.

  • Incorrect behavior is often the result of

incorrect state.

  • Tabulate the values of all fields.
  • Document state changes after each method

call.

slide-18
SLIDE 18

10/11/2005 Lecture 6: Wel-behaved Objects 18

Verbal walkthroughs Verbal walkthroughs

  • Explain to someone else what the code is

doing.

  • They might spot the error.
  • The process of explaining might help you to

spot it for yourself.

  • Group-based processes exist for conducting

formal walkthroughs or inspections.

slide-19
SLIDE 19

10/11/2005 Lecture 6: Wel-behaved Objects 19

Print statements Print statements

  • The most popular technique.
  • No special tools required.
  • All programming languages support them.
  • Only effective if the right methods are

documented.

  • Output may be voluminous!
  • Turning off and on requires forethought.
slide-20
SLIDE 20

10/11/2005 Lecture 6: Wel-behaved Objects 20

Debuggers Debuggers

  • Debuggers are both language- and

environment-specific.

  • BlueJ has an integrated debugger.
  • Support breakpoints.
  • Step and Step-into controlled execution.
  • Call sequence (stack).
  • Object state.
slide-21
SLIDE 21

10/11/2005 Lecture 6: Wel-behaved Objects 21

Review Review

  • Errors are a fact of life in programs.
  • Good software engineering techniques can

reduce their occurrence.

  • Testing and debugging skills are essential.
  • Make testing a habit.
  • Automate testing where possible.
  • Practise a range of debugging skills.
slide-22
SLIDE 22

Designing classes Designing classes

How to write classes in a way that they are easily understandable, maintainable and reusable

slide-23
SLIDE 23

10/11/2005 Lecture 6: Wel-behaved Objects 23

Main concepts to be covered Main concepts to be covered

  • Responsibility-driven design
  • Coupling
  • Cohesion
  • Refactoring
  • Static methods
slide-24
SLIDE 24

10/11/2005 Lecture 6: Wel-behaved Objects 24

Software changes Software changes

  • Software is not like a novel that is written
  • nce and then remains unchanged.
  • Software is extended, corrected, maintained,

ported, adapted…

  • The work is done by different people over

time (often decades).

slide-25
SLIDE 25

10/11/2005 Lecture 6: Wel-behaved Objects 25

Change or die Change or die

  • There are only two options for software:
  • Either it is continuously maintained
  • or it dies.
  • Software that cannot be maintained will be

thrown away.

slide-26
SLIDE 26

10/11/2005 Lecture 6: Wel-behaved Objects 26

World of World of Zuul Zuul

slide-27
SLIDE 27

10/11/2005 Lecture 6: Wel-behaved Objects 27

Code quality Code quality

Two important concepts for quality of code:

  • Coupling
  • Cohesion
slide-28
SLIDE 28

10/11/2005 Lecture 6: Wel-behaved Objects 28

Coupling Coupling

  • Coupling refers to links between separate

units of a program.

  • If two classes depend closely on many

details of each other, we say they are tightly coupled.

  • We aim for loose coupling.
slide-29
SLIDE 29

10/11/2005 Lecture 6: Wel-behaved Objects 29

Loose coupling Loose coupling

Loose coupling makes it possible to:

  • understand one class without reading others;
  • change one class without affecting others.
  • Thus: improves maintainability.
slide-30
SLIDE 30

10/11/2005 Lecture 6: Wel-behaved Objects 30

Cohesion Cohesion

  • Cohesion refers to the the number and

diversity of tasks that a single unit is responsible for.

  • If each unit is responsible for one single

logical task, we say it has high cohesion.

  • Cohesion applies to classes and methods.
  • We aim for high cohesion.
slide-31
SLIDE 31

10/11/2005 Lecture 6: Wel-behaved Objects 31

High cohesion High cohesion

High cohesion makes it easier to:

  • understand what a class or method does;
  • use descriptive names;
  • reuse classes or methods.
slide-32
SLIDE 32

10/11/2005 Lecture 6: Wel-behaved Objects 32

Cohesion of methods Cohesion of methods

  • A method should be responsible for one and
  • nly one well defined task.
slide-33
SLIDE 33

10/11/2005 Lecture 6: Wel-behaved Objects 33

Cohesion of classes Cohesion of classes

  • Classes should represent one single, well

defined entity.

slide-34
SLIDE 34

10/11/2005 Lecture 6: Wel-behaved Objects 34

Code duplication Code duplication

Code duplication

  • is an indicator of bad design,
  • makes maintenance harder,
  • can lead to introduction of errors during

maintenance.

slide-35
SLIDE 35

10/11/2005 Lecture 6: Wel-behaved Objects 35

Responsibility Responsibility-

  • driven design

driven design

  • Question: where should we add a new

method (which class)?

  • Each class should be responsible for

manipulating its own data.

  • The class that owns the data should be

responsible for processing it.

  • RDD leads to low coupling.
slide-36
SLIDE 36

10/11/2005 Lecture 6: Wel-behaved Objects 36

Localizing change Localizing change

  • One aim of reducing coupling and

responsibility-driven design is to localize change.

  • When a change is needed, as few classes as

possible should be affected.

slide-37
SLIDE 37

10/11/2005 Lecture 6: Wel-behaved Objects 37

Thinking ahead Thinking ahead

  • When designing a class, we try to think

what changes are likely to be made in the future.

  • We aim to make those changes easy.
slide-38
SLIDE 38

10/11/2005 Lecture 6: Wel-behaved Objects 38

Refactoring Refactoring

  • When classes are maintained, often code is

added.

  • Classes and methods tend to become longer.
  • Every now and then, classes and methods

should be refactored to maintain cohesion and low coupling.

slide-39
SLIDE 39

10/11/2005 Lecture 6: Wel-behaved Objects 39

Refactoring and testing Refactoring and testing

  • When refactoring code, separate the

refactoring from making other changes.

  • First do the refactoring only, without

changing the functionality.

  • Test before and after refactoring to ensure

that nothing was broken.

slide-40
SLIDE 40

10/11/2005 Lecture 6: Wel-behaved Objects 40

Design questions Design questions

Common questions:

  • How long should a class be?
  • How long should a method be?
  • Can now be answered in terms of cohesion

and coupling.

slide-41
SLIDE 41

10/11/2005 Lecture 6: Wel-behaved Objects 41

Design guidelines Design guidelines

  • A method is too long if it does more then
  • ne logical task.
  • A class is too complex if it represents more

than one logical entity.

  • Note: these are guidelines - they still leave

much open to the designer.

slide-42
SLIDE 42

10/11/2005 Lecture 6: Wel-behaved Objects 42

Review Review

  • Programs are continuously changed.
  • It is important to make this change possible.
  • Quality of code requires much more than

just performing correct at one time.

  • Code must be understandable and

maintainable.

slide-43
SLIDE 43

10/11/2005 Lecture 6: Wel-behaved Objects 43

Review Review

  • Good quality code avoids duplication,

displays high cohesion, low coupling.

  • Coding style (commenting, naming, layout,

etc.) is also important.

  • There is a big difference in the amount of

work required to change poorly structured and well structured code.

slide-44
SLIDE 44

10/11/2005 Lecture 6: Wel-behaved Objects 44

Static Methods Static Methods

  • Previous we discussed class and object

level.

  • We introduced class variables
  • static keyword
  • A similar thing can be done for methods

providing services for the class instead an

  • bject
slide-45
SLIDE 45

10/11/2005 Lecture 6: Wel-behaved Objects 45

Static Methods (2) Static Methods (2)

public class StaticTest { static count = 0; public StaticTest { count++; } public static int giveCount() { return count; } … }

slide-46
SLIDE 46

10/11/2005 Lecture 6: Wel-behaved Objects 46

Executing without Executing without BlueJ BlueJ

  • If we want to start a Java application

without BlueJ, we need to use a class method.

  • Java uses a class method with a specific

signature:

  • public static void main(String args[])
  • args contains the command line options for

your application

slide-47
SLIDE 47

10/11/2005 Lecture 6: Wel-behaved Objects 47

Executing without Executing without BlueJ BlueJ (2) (2)

  • Compiling
  • javac className.java
  • Running
  • java className
  • java className command line options
  • but className should contain a main method
  • BlueJ write its own main whenever you ask

it to execute something.

slide-48
SLIDE 48

10/11/2005 Lecture 6: Wel-behaved Objects 48

Concepts Concepts

  • testing
  • positive and negative

testing

  • debugging
  • unit testing
  • regression testing
  • walkthroughs
  • responsibility-driven

design

  • coupling
  • cohesion
  • refactoring
  • static
  • class methods
  • main method