CS计算机代考程序代写 prolog Java algorithm junit SWEN20003 Object Oriented Software Development

Comments appearing before code are like a “prologue” for your code;
they introduce the idea of the code before you actually try to digest it.

Software Testing and Design SWEN20003 8 / 36

Boring Stuff (Javadoc)

javadoc.equals(comments); // false

Javadoc is a special kind of comment that can be compiled to
HTML

Intended primarily for developers using your program (exactly like
Slick documentation)

Used to document packages, classes, methods, and attributes (among
others)

Should document how to use and interact with your classes and their
methods

Various @ tags (like @param and @return) for generating specific
documentation

Software Testing and Design SWEN20003 9 / 36

Project Expectations (Javadoc)

You must include Javadoc documentation in your project 2 submission:

All public classes, attributes, and methods

Yes, this includes getters, setters, and constructors (hint, some things
can be auto-generated)

You do not need to use any fancy @ tags, just provide @param and
@return when appropriate

No, we’re not generating the HTML of your Javadoc

Software Testing and Design SWEN20003 10 / 36

Software Design

Software Testing and Design SWEN20003 11 / 36

Poor Design Symptoms

Think about how the following slide can be applied to your
current/expected implementation of Project 2.

Imagine how difficult it would be for you to change/fix/update your
solution if you identified a problem, or if the specification changed.

Software Testing and Design SWEN20003 12 / 36

Poor Design Symptoms

Rigidity Hard to modify the system because changes in one class/method
cascade to many others

Fragility Changing one part of the system causes unrelated parts to break

Immobility Cannot decompose the system into reusable modules

Viscosity Writing “hacks” when adding code in order to preserve the design

Complexity Lots of clever code that isn’t necessary right now; premature
optimisation is bad

Repetition Code looks like it was written by Cut and Paste

Opacity Lots of convoluted logic, design is hard to follow

Software Testing and Design SWEN20003 13 / 36

GRASP

In SWEN30006 you’ll learn about

G General

R Responsibility

A Assignment

S Software

P Patterns/Principles

Keyword

GRASP: A series of guidelines for assigning responsibility to classes in an
object-oriented design; how to break a problem down into modules with
clear purpose.

Software Testing and Design SWEN20003 14 / 36

GRASP Basics

Keyword

Cohesion: Classes are designed to solve clear, focused problems. The class’
methods/attributes are related to, and work towards, this objective.
Designs should have maximum cohesion.

Keyword

Coupling: The degree of interaction between classes; dependency between
classes. Designs should have minimum (low) coupling.

Software Testing and Design SWEN20003 15 / 36

GRASP Basics

Keyword

Open-Closed Principle: Classes should be open to extension, but closed
to modification.

In practice, this means if we need to change or add functionality to a
class, we should not modify the original, but instead use inheritance.

Software Testing and Design SWEN20003 16 / 36

GRASP Basics

Keyword

Abstraction: Solving problems by creating abstract data types to represent
problem components; achieved in OOP through classes, which represent
data and actions.

Keyword

Encapsulation: The details of a class should be kept hidden or private, and
the user’s ability to access the hidden details is restricted or controlled.
Also known as data or information hiding.

Software Testing and Design SWEN20003 17 / 36

GRASP Basics

Keyword

Polymorphism: The ability to use an object or method in many different
ways; achieved in Java through ad hoc (overloading), subtype (overriding,
substitution), and parametric (generics) polymorphism.

Keyword

Delegation: Keeping classes focused by passing work to other classes.
Computations should be performed in the class with the greatest amount
of relevant information.

Software Testing and Design SWEN20003 18 / 36

Software Testing

Software Testing and Design SWEN20003 19 / 36

A bit about myself and my research

Keyword

Why software testing matters?: The cost of software bugs can be huge,
e.g., peoples’ lives and money.

Software Testing and Design SWEN20003 20 / 36

Bug Fixing

How do you normally find/fix a bug?

Print statements

System.out.println(“Why does my code not reach here?”);

Google

How to fix my Java code

Forums (Stackoverflow, etc.)

Someone please help my code is broken

Software Testing and Design SWEN20003 21 / 36

Bug Fixing

Java offers a structured method for testing, very important for COMP30022:

Keyword

Unit: A small, well-defined component of a software system with one, or a small
number, of responsibilities.

Keyword

Unit Test: Verifying the operation of a unit by testing a single use case
(input/output), intending for it to fail.

Keyword

Unit Testing: Identifying bugs in software by subjecting every unit to a suite of
tests.

Software Testing and Design SWEN20003 22 / 36

Creating Units

What are the fundamental units of this method?

public boolean makeMove(Player player, Move move) {

int row = move.row;

int col = move.col;

if (row < 0 || row >= SIZE || col < 0 || col >= SIZE ||

!board[row][col].equals(EMPTY)) {

return false;

}

board[row][col] = player.getCharacter();

return true;

}

Software Testing and Design SWEN20003 23 / 36

Creating Units

public boolean cellIsEmpty(Move move) {

return board[move.row][move.col].equals(EMPTY);

}

public boolean onBoard(Move move) {

return move.row >= 0 && move.row < SIZE && move.col >= 0 && move.col < SIZE; } public boolean isValidMove(Move move) { if (onBoard(move) && cellIsEmpty(move)) { return true; } return false; } public void makeMove(Player player, Move move) { board[move.row][move.col] = player.getCharacter(); } Software Testing and Design SWEN20003 24 / 36 Unit Testing With Java Much better! What now? Keyword Manual Testing: Testing code manually, in an ad-hoc manner. Generally difficult to reach all edge cases, and not scalable for large projects. Keyword Automated Testing: Testing code with automated, purpose built software. Generally faster, more reliable, and less reliant on humans. Software Testing and Design SWEN20003 25 / 36 JUnit Testing Keyword assert: A true or false statement that indicates the success or failure of a test case. Keyword TestCase class: A class dedicated to testing a single unit. Keyword TestRunner class: A class dedicated to executing the tests on a unit. Software Testing and Design SWEN20003 26 / 36 TestCase Class import static org.junit.Assert.*; import org.junit.Test; public class BoardTest { @Test public void testBoard() { Board board = new Board(); assertEquals(board.cellIsEmpty(0, 0), true); } @Test public void testValidMove() { Board board = new Board(); Move move = new Move(0, 0); assertEquals(board.isValidMove(move), true); } } Software Testing and Design SWEN20003 27 / 36 TestCase Class @Test public void testMakeMove() { Board board = new Board(); Player player = new HumanPlayer("R"); Move move = new Move(0, 0); board.makeMove(player, move); assertEquals(board.getBoard()[move.row][move.col], "r"); } Software Testing and Design SWEN20003 28 / 36 TestRunner Class import org.junit.runner.JUnitCore; import org.junit.runner.Result; import org.junit.runner.notification.Failure; public class TestRunner { public static void main(String[] args) { Result result = JUnitCore.runClasses(BoardTest.class); for (Failure failure : result.getFailures()) { System.out.println(failure.toString()); } System.out.println(result.wasSuccessful()); } } Software Testing and Design SWEN20003 29 / 36 TestRunner Class testMakeMove(BoardTest): expected:<[r]> but was:<[R]>

false

Software Testing and Design SWEN20003 30 / 36

Assess Yourself

Write a unit test to verify that when a move is made off the board, the
isValidMove method returns false.

There are actually (at least) four test cases for this, but here’s one:

@Test

public void testValidMove2() {

Board board = new Board();

Move move = new Move(-1, 0);

assertEquals(false, board.isValidMove(move));

}

Software Testing and Design SWEN20003 31 / 36

JUnit Advantages

Large teams and open source development (should) always use
automated testing:

Easy to set up

Scalable

Repeatable

Not human intensive

Incredibly powerful

Finds bugs

We don’t expect you to use it, but getting used to automated testing
makes you more useful in a team.

Here’s an example.

Software Testing and Design SWEN20003 32 / 36

https://github.com/facebook/react

Assess Yourself

What units, use cases, and unit tests could you write for Project 2B?

Again, we don’t expect you to do this.

Software Testing and Design SWEN20003 33 / 36

Software Testing and QA Jobs

Keyword

Software Tester: Conducts tests on software, primarily to find and
eliminate bugs.

Software Testing and Design SWEN20003 34 / 36

Software Testing and QA Jobs

Keyword

Software Quality Assurance: Actively works to improve the development
process/lifecycle. Directs software testers to conduct tests, primarily to
prevent bugs.

Software Testing and Design SWEN20003 35 / 36

Metrics

Documentation
This will be assessed in the project, but not the exam.

Software Design
You will need to be able to define the keywords defined in this lecture. You will
need to know definitions for the exam, but you will not be assessed on software
design principles by writing code.

Software Testing

You will need to be able to define the keywords as well as implement a unit test

for the exam. You will not be asked to write a TestRunner class, only one or two

standalone test cases.

Software Testing and Design SWEN20003 36 / 36