Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Coweb Assignement 3:
Usability (2 Points)
You've learned about three usability evaluation techniques in this class: heuristic evaluation, cognitive walkthrough, and observing users. Compare and contrast two of these. What are the strengths of each approach? What are the weaknesses? When are they appropriate to use? Why would you choose one over the other?
Heuristic evaluation of a program involves an independent evaluation team judging an interface using a set of heuristics as a guide. Any usability bugs found by the evaluators are recorded and described. The evaluation team then meets and organizes their list of bugs, assigning each a severity rating based on how frequency, impact, persistence, and market impact of the bug. This list of bugs is then given back to the design team as recommendations for revision. Observing users is another technique for evaluating an interface. The general method for this type of evaluation is to observe someone who is not familiar with the project interacting with the system. Generally, it is also beneficial to record the user's thought process as they interact with the system by either having them talk aloud as they use the interface, or by recording their actions somehow and asking them to describe their thoughts at a later time.
User observation is probably one of the best evaluation techniques for a system because it involves real users from the target audience using and evaluating the program. This provides the designers with useful feed back from the end-users themselves. Unfortunately, this requires finding people from the target audience willing to sit down and actually test the interface and recording their thought processes and expectations of the interface as accurately as possible without influencing them in anyway, which could be difficult since most people do not describe their actions aloud during normal use. For these reasons a heuristic evaluation may be the next best thing for finding bugs. Given a large enough team of evaluators, most bugs will indeed be found and although the feedback may not be as useful as that of members of the target audience, it is generally easier to conduct a heuristic evaluation than user observation. Furthermore, since the evaluators record their own thoughts it would be more difficult to influence their thinking than it would to influence a user while observing them. The heuristic evaluation is limited however in that it can only be as good as the heuristics that are being used. If insufficient heuristics are used to evaluate the interface bugs could slip through the cracks. This could also happen if the evaluators are not thorough in their evaluation.
In summary, a user observation evaluation would be most appropriate when a fully-working prototype and users from the target audience are available and the evaluators are careful to conduct the observation in such a way as to record a user's thought processes without influencing them. If the feedback from an actual user is desired, possibly because the target audience is a specific group (say children for example), user observation is really the only way to judge the interface from a user's point of view. A heuristic evaluation, on the other hand, provides useful feedback in the form of a bug list and could be used to find most bugs relatively quickly and easily assuming a good set of heuristics is used and the evaluators are thorough. The severity rating assigned by the evaluation team might is also an added benefit when choosing this evaluation technique.
Design Patterns (2 Points)
(Part A) Besides its name, name three characteristics commonly used to describe design patterns. For each characteristic, describe what it is and why it is useful? (Part B) Observer, Adaptor, and Factory are three design patterns described in this class. For two of these three, briefly describe them using the characteristics you chose.
Besides their name, design patterns are also described by three other characteristics:
- The problem they solve, or when it is appropriate to apply a pattern
- The solution, or how the design pattern actually solves the pattern, including its relationships and responsibilities.
- The consequences, or tradeoffs involved with using a pattern
- The observer design pattern is characterized as a solution to the problem of notifying and updating many dependent objects of changes to another object. The observer pattern solution generally involves a subject object that is able to add or remove observer objects, which can update themselves when notified of changes to the subject. Generally, there could be many observers of a single subject or possibly an observer that observes multiple subjects. This is solution is rather robust but also has some important consequences. One example is that the coupling required of the subjects and observers could be computationally expensive or difficult to maintain if there are many interdependent objects. Also, the cost of updating is not known by subjects when they notify their observers and so cascading or unecessary updates could create problems. Finally, we have to develop a framework for adding, removing, and notifying observers of changes, although there are existing frameworks for this.
- The factory design pattern is characterized as a solution to providing flexible object creation instead of hardcoding a single class for a given implementation. Essentially, objects are created indirectly and the factory allows for the programmer to specify only the interface needed by a given object and not the class (implementation) itself. This is useful in situations in which the proper class of object for a given situation may vary or the class wants to allow subclasses to specify the type of object to create. The implementation of the factory design pattern generally involves an abstract product class that defines the common interface features that all products of the factory will share, and a creator or factory class that defines methods for creating a product. These abstract interfaces can then be implemented by specific versions of a product and the factory that creates this specific product. Some drawbacks to this approach include having to define a creator class for every product, which means there will be two parallel, but connected, class hierarchies to maintain.
Coweb Assignment 2:
The debugger is a useful tool that allows you to easily trace execution of a program and find sources of errors. To use the debugger click debug in the pink system window that opens when an error occurs. You can also halt execution and open a debugger anywhere in your program by including the line:
The debugger allows you to view and edit the code of your program during execution. You can step through line by line and see how the state of current variables in scope change to find bugs in your code. The value of any class or temp variable can be viewed by clicking on it in the bottom list. For class objects that don't show useful information you can also right-click on a variable and inspect its contents.
The debugger also has a few useful tools that let you see exactly what your code is doing line by line:
- Proceed: The proceed button continues normal execution of the program. This could be useful if you think you've fixed any errors.
- Restart: Restarts the debugger and resets execution to wherever it started.
- Into: Executes a line of code at a time and steps into message calls. This is useful if you think another method is causing the problem since you can step into it and see what it is doing and what it returns.
- Over: Executes a line of code without stepping into other methods. This skips message calls and allows you to analyze the state of the program after each line of code.
- Through: Steps into a block of code. Useful for anything with the block construct.
- Full stack: Shows a full stack trace or all the variables in current use.
Coweb Assignment 1:
Tracing Code (1 point):
The following code solves the rainfall problem, which you may have seen in previous CS classes. For each line, describe what the Smalltalk code does. Be as specific as possible. In particular, what is data at the various points in the code?
| data onlyPositiveNumbers |
This line declares two temporary or method variables named data and onlyPositiveNumbers. At this point they are unitialized.
data := OrderedCollection withAll: #(1 2 3 -4 -5 'error' 6 -7 999 2).
This line creates a new OrderedCollection object that contains a list of values and assigns this to the variable data. At this point data contains an OrderedCollection with the values 1, 2, 3, -4, -5, 'error', 6, -7, 999, and 2. Note that the OrderedCollection does not sort the data numerically but behaves similar to an array in that the order of the objects in the collection is preserved (ie. 1 is the first element in this case, -4 is the fourth element, etc.).
onlyPositiveNumbers := [:i | (i isKindOf: Number) and: [i positive]].
This code snippet contains a block that given an object will return true if and only if i is a Number and i is positive. This block is then assigned to the variable onlyPositiveNumbers. Thus we can now use onlyPositiveNumbers as if it were a block, this allows us to send it a value by sending the message value followed by an object and it will return a Boolean based on whether the object is a number and if it is positive.
data := data select: onlyPositiveNumbers.
This line of code sends the select message to the OrderedCollection object, data, and passes the Block object, onlyPositiveNumbers. This method then iterates over all values in the OrderedCollection and removes all values for which onlyPositiveNumbers evaluates to false. Data now contains only positive numbers.
data := data copyUpTo: 999. "not including"
This line of code removes all data elements greater than or equal to 999 by sending itself the copyUpTo message, which returns an OrderedCollection with all elements less than 999 (in this case). Data now contains positive numbers less than 999.
Transcript show: data average
This line of code prints the average of the remaining values in the OrderedCollection data to the transcript.
Writing Code (1 point)
((anInteger isKindOf: Integer) and: [anInteger >= 0]) ifFalse: [^self error: 'Invalid input'].
((anInteger = 1) or: [anInteger = 0]) ifTrue: [^1]
ifFalse: [ ^((self fib: (anInteger - 1)) + (self fib: (anInteger - 2)))].
Links to this Page