WriteUp.docx - Google Code

looneyvillestaticΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 4 χρόνια και 10 μήνες)

225 εμφανίσεις

Write Up


Design Checklist

1.

Have you included a UML class diagram for all your classes?

We have included a UML class diagram for all your classes.

2.

Does your design go down to the
function level
? Have you defined all the major
functions your program will include and what each one of them should do?

Yes, our design goes down to the function level. We have defined all the major functions
of our program and what each should do.

3.

Do you have a speci
fication document that lists every class, what the class does, and
every member function and what it does?

Yes, we
have a specification document.

4.

Have you iterated, selecting the best of several attempts rather than the first attempt?

Yes, we went throu
gh many attempts before we had our final decision.

5.

Have you tried decomposing the system in several different ways to see which way will
work best?

Yes, we decomposed the system in several different ways to see which way worked best.

6.

Have you approached t
he design problem from the top down or from the bottom up?

For the GUI we did top down and for the Generating we did bottom up.

7.

Have you prototyped risky or unfamiliar parts of the system, creating the absolute
minimum of
throwaway

code needed to answer s
pecific questions?

Yes, we have prototyped risky parts of the system, which in turn creates the absolute
minimum of throwaway code needed.

8.

Has your design been reviewed by others?

Yes, it has been reviewed by each member of the group.


9.

Have you driven the design to the point that
its implementation seems obvious
?

The design’s implementation seems obvious.

10.

Does the design meet the requirements?

Yes, it meets the requirements.

11.

Are you satisfied with the way the program has been decompos
ed into subsystems,
packages, and classes?

Yes, we are satisfied with the way the program has been decomposed into subsystems,
packages, and classes.

12.

Are you satisfied with the way the classes have been decomposed into routines?

Yes, we are satisfied with

the way the classes have been decomposed into routines.

13.

Do the classes have good names? Do the functions have good names?

Yes our classes and functions have meaningful names.

14.

Are classes designed for minimal interaction with each other?

No, they depend

on each other.

15.

Is the design lean? Are all of its parts strictly neccessary?

No, our classes have lines of code in the hundreds. And yes, all the parts are necessary.

16.

Does the design help minimize both accidental and essential complexity?

Yes, the desi
gn helps minimize both accidental and essential complexity.

17.

Will you be using the pseudocode programming process of Chapter 9?

No, we did not use the pseudocode programming process of the book.





Coding Checklist:


Variables

1.

Do you always ensure that argument values are valid?


No, because certain values are expected.


2.

Declare variables close to where they are used.


Yes


3.

Initialize variables as they are declared.


Yes


4.

Do all variables have the smallest scope possible?


Yes


5.

Are references to variables as close as possible?


Never used any references.


6.

Do control structures correspond to data types?



We have no control structures.


7.

Are all declared variables used?


We believe so.


8.

Does each variable have one and only one p
urpose?


Yes


9.

Is each variables meaning, and name, explicit? with no hidden meanings?


Yes


10.

Do your variable names follow your coding practice?


Yes


11.

Does the name refer to the real
-
world problem rather than the programming
-
language
solution?


Yes


12.

Is the
name long enough that you don't have to guess?


Yes

13.

Are computed
-
value qualifiers at the end of the name?


No, because we don't know what that means.


14.

Are loop index variable names meaningful? i and j should only be used for loops of only
a couple of lines
.


15.

Have you named all temporary variables?


No, we used i and j multiple times as well as some other variables.


16.

Have you re
-
named all "temporary" variables?


Yes


Data Types

1.

Do you have any magic numbers?


No, they have been relocated to a separate
class.


2.

Does the code anticipate divide by zero errors?


No, because we do not divide by anything.


3.

Are type conversion obvious?


No, we never type
-
cased anything.


4.

Do you avoid mixed
-
type comparisons?


Yes


5.

Are you doing integer division?


No, because we

did not divide by an integer.


6.

Are you checking for integer overflow?


No, we deal with integers 1 through 9, nothing bigger.


7.

Do you avoid adding or subtracting floating point numbers of very different magnitudes?


No, we have no decimal values.


8.

Do
you avoid comparing floating point numbers for equality?


No, we have no decimal values.


9.

Does the program use additional boolean variables to document

conditional tests? to simplify
tests?


At first we used boolean tests, they were removed upon success.


10.

Do you use enumerated types instead of named constants when appropriate?


No, we use neither.



11.

Are all array indexes within the bounds of the array?


Yes, but we used vectors rather than arrays.


12.

Are array references free of off
-
by
-
one errors?


Yes, bu
t we have no array references.


13.

Are type names oriented towards the real
-
world entities the types represent rather than
toward programming
-
language types?


Yes


14.

Have you avoided re
-
defining predefined types?


Yes


Statements

1.

Does the code make
dependencies among statements obvious?


Yes


2.

Do the names of routines make dependencies obvious?


Yes


3.

Do parameters to routines make dependencies obvious?


Yes


4.

Do comments describe any dependencies that would otherwise be unclear?


Yes


5.

Does the code rea
d from top to bottom?


Yes


6.

Are related statements grouped together?


Yes


7.

Have relatively independent groups of statement been moved into their own routines?


Yes


Conditionals

1.

Is the nominal path through the code clear?


Yes


2.

Is the else clause present
and documented?


Yes


3.

Are the if and else clauses used correctly

not reversed?


Yes

4.

Does the normal case follow the if rather than the else?


Yes


5.

Are complicated tests encapsulated in boolean function calls?


Yes


6.

Are the most common cases tested first?


Yes


7.

Are all cases covered?


Yes


Loops

1.

Is a while loop used instead of a for when appropriate?


Yes


2.

Is the initialization code directly before the loop?


Yes


3.

If it is an infinite loop, is it clear that it is? Is any exit clear?


Yes


4.

Is the loop body
nonempty?


Yes


5.

Does the loop perform one and only one function, as a well
-
defined routine does?


Yes


6.

Is the loop short enough to view all at once?


Yes


7.

Is the loop nested to three levels or less?


Yes


8.

In a for loop, do you avoid changing the index vari
able?


No, we use indexes to gauge Sudoku positions, sometimes manually changing it.


9.

Do you avoid using the index variable outside the loop?



Yes


10.

Does the index variable have a meaningful name?


No, we used alphabetical indexes.


11.

Does the loop avoid
crosstalk?


No, nobody knows what crosstalk is.

12.

Does the loop end under all possible conditions?


Yes


13.

Does the loop use safety counters?


No, it does not.


14.

Is the loop's termination condition obvious?


Yes


Testing Checklist

1.

Does each requirement have
its own test case?


No, we tested only the Sudoku class. In the Sudoku class each method is tested.


2.

Has each line of code been tested with at least one test case?

Each method has been tested in the Sudoku class.


3.

Have all paths thru your code been
excersized and tested?


All paths in the Sudoku class has been tested with different data.



4.

Have all simple boundaries been tested: maximum, minimum, and off
-
by
-
one
boundaries?


Yes, we tested the class with different file input.



5.

Do tests cases check fo
r the wrong kind of data: when the user enters a string a you are
expecting a number? or he types in an empty string? or the data file is empty?

Yes, we tested if the data was the wrong number, null, or if the file that is inputting is
empty.



6.

Are your un
it tests run automatically?

No, we run our unit test in Junit, which was apart of the NetBeans IDE. We, manually
test the Sudoku class.


7.

Are your integration tests run automatically?

No, we test it manually in NetBeans.


List of Bugs found on the Matrix C
alculator

Provided by the Capstone Sudoku group.


The provided instructions were difficult to follow and should be slightly more elaborate.


The provided instructions fail to distinguish between operating systems and should at least
mention which system
the instructions are for.


Adding the application to the emulator required command line with administrative permissions.
These privileges were not mentioned in the provided instructions.


The provided instructions fail to provide assistance in navigating
the Android operating system.


Upon our first successful entry into the app, the emulator crashed. We were unable to replicate
this problem.


Within the app, the "constant multiplication" operation does not work unless the constant is
positioned as the ri
ght
-
most entry.


Within the app, on the matrix
-
input screen, the center button is not clearly labeled. We found out
that clicking this button swaps the two entries. This button should have a colorful, evident
symbol to show the user what it is for.


We co
uld not figure out how to input the vector brackets ( "<" or ">" ).

Final Analysis

Our proposed inputs of mouse hovering, clicking and numeric input ended up being used. We
also carried out our goal of implementing menus regarding "finish", "hint", "new ga
me", and
"help". However, our help menu has expanded to also include color options. We have also added
a sudoku editor mode that we had not foreseen.


Our proposed functions for each of these menu options have been completed as planned.
However, there are

some differences from our planned interface. Our new interface changes only
typed entries to red if they are incorrect.


If we were to do all this again, a separate class for the Sudoku board should be created first.
Also, SVN should also be figured out
at the beginning so collaboration will be easier. A large
problem we ran into was not having an exact plan for creating the generating class. If we had
another chance at this project, we would definitely attempt to plan out a proper way to generate a
Sudok
u board before attempting to code it.


Looking at the UML diagram, it was very basic. Over the weeks, we created more classes that
would make the Sudoku game run more efficiently.

With testing, we never created a testing class to test our methods/code.
We would not do
anything differently with the testing side because we learned how to test the class, and if we have
to test a class or method in the future, we now know how to do so.