midterm_fa07.pdf

University of Illinois at Urbana-Champaign
Department of Computer Science
Midterm Exam Solutions
CS 427 Software Engineering 1
Fall 2007
October 23, 2007
TIME LIMIT = 1 hour 15 minutes
COVER PAGE + 12 PAGES
Print your name and netid neatly in the space provided below; print your netid in the upper right
corner of every page.
Name:
Netid:
This is a closed book, closed notes examination. You may not use calculators or any other electronic
devices. Any sort of cheating on the examination will result in a zero grade.
We cannot give any clarifications about the exam questions during the test. If you are
unsure of the meaning of a specific question, then write down your assumptions and proceed to
answer the question on that basis.
Do all the problems in this booklet. Do your work inside this booklet, using the backs of pages
if needed. The problems are of varying degrees of difficulty so please pace yourself carefully, and
answer the questions in the order which best suits you. Answers to essay-type questions should be
as brief as possible. If the grader cannot understand your handwriting you may get 0 points.
There are 17 questions on this exam and the maximum grade on this exam is 90 points.
Page Points Score
1 9
2 9
3 9
4 11
5 12
6 10
7 8
8 8
10 6
11 8
Total: 90

CS 427 Midterm Exam netid:
1. Golden Rule of Version Control software
(a)
4 According to Prof. Johnson, the golden rule of version control is to check-in files quickly.
Give two reasons why this is true.
Solution:
Refer to Lecture 2, slide 24
• The longer you hold on to your changes, the more you interfere with others since
you might have critical changes that will change the design of the system and
this should be propagated to the mainline quickly so that everyone else will use
this new design.
• The longer you have code checked out the harder it is to merge (for you and
other developers) since multiple changes might have occurred.
(b)
1 Does this rule apply to editing the wiki too? If so, describe how. If not, explain why not.
Solution:
Yes. The longer a person delays committing his/her changes, the more likely that other
people would make changes to the same page on the wiki. In the end, the person who
holds the page longest without committing would have the hardest task of merging all
the commits that have occurred.
2. Branch mania refers to the situation where branches are created often and for no apparent
reason. It is an anti-pattern and should be avoided. However, branching, when done properly,
can also be beneficial.
(a)
2 What are two benefits of branching?
Solution:
• Branching increases productivity by allowing parallel development.
• Branching helps reduce risk by isolating experimental changes from breaking the
mainline.
(b)
2 Give two situations when a branch should be created.
Solution:
• To try out a new experimental version using new tools/ technology.
• To add a new component/ task that might interfere with the mainline.
• To split a separate release that no longer meets the vision and goals of the original
developer.
Page 1 of 12 Please go on to the next page. . .

CS427 (Continued) Midterm Exam netid:
(c)
1 What is the main cost of branching?
Solution:
Merging. You would eventually have to merge some branches back into the mainline
and depending on how much that branch has deviated the merge process could be
very complicated.
3.
2 According to Brad Appleton, before committing to the repository, you should always do a
Private System Build to avoid breaking the build. List two things that you need to run during
a Private System Build to ensure that your code will not break the build.
Solution:
Refer to Lecture 3, slide 37
• Run tests (smoke tests, unit tests, regression tests)
• Run build system (ant, make).
• Run integrated system like cruise control.
4. One of the best practices of XP is test first. In fact, the authors of Extreme Software Engineering
claim that testing first helps you write better code.
(a)
4 Give two reasons for their claim.
Solution:
Refer to Extreme Software Engineering p. 57 - 61
• Testing forces simplicity
• Testing clarifies the task at hand
• Testing frees you from on-the-fly editing
(b)
2 Must you write a test for every method or function? Explain your answer.
Solution:
No, you are not required to write a test for every method. You must write explicit test
to ensure that every aspect of the requirements are satisfied. (i.e. black box tests). It
is a best practice to write (white box) tests such that as much up of the code is covered
as is possible. However, this does not mean that a test for every method is required.
Some methods (such as accessors) are so trivial they do no necessarily require their
own dedicated tests.

5. Automated testing
(a)
2 Give one reason why automated tests are important in XP.
Solution:
You can easily run automated tests to check if your refactoring has broken some
functionality. This fast feedback – compared to manual tests – allows you to make
changes more confidently and quickly.
(b)
2 Give two features that an automated testing framework like JUnit offers to the developer
to make testing more effective.
Solution:
Any reasonable feature is acceptable.
• Visual feedback (red/green bar) that lets you know quickly if something is bro-
ken.
• Ability to identify and jump quickly to the source of error.
• Tests are decoupled from your classes – you can easily release a product without
including the tests since the classes make no reference to those tests.
(c)
2 Why does Brian Marrick says that attempting to automate all tests is a bad idea.
Solution:
Some tests will be only be run infrequently such that benefit gained does not com-
mensurate with the cost of automation.
6.
3 List three types of tools for testing that we have mentioned in class. (Hint: We used two of
them in the MPs)
Solution:
• Unit Testing Framework – JUnit
• Code Coverage Tool – EclEmma
• Functional GUI Testing – FEST

7.
2 Name two tools that you could use for debugging.
Solution:
• Debugger
• Logging system e.g. log4j
8. Configuration Management for projects
(a)
3 We mentioned three kinds of tools for configuration management. What are they?
Solution:
• Version Control
• Build System
• Change Control
(b)
2 Eclipse does two of these things automatically for Java programs. What are they?
Solution:
• CVS
• Build System
• Mylyn (task list) in Eclipse 3.3
9.
4 Companies sometimes distribute beta programs over the internet as a way to test their software.
According to Brian Marrick, an over-reliance on beta testing is a classical testing mistake.
Give two reasons for his claim.
Solution:
Refer to the over-reliance on beta testing section in Classical Testing Mistakes
• Beta users are not committed to testing it thoroughly.
• Beta users might not report all problems (even serious ones).
• Beta users are not a good representation of the majority of end-users will who be
using the product since they have different priorities.

10.
6 Pair programming is another best practice principles of XP. What are two advantages of pair
programming? What is one disadvantage of pair programming?
Solution:
Advantages
• Constant code reviews. Errors are caught more quickly - two sets of eye on the code.
• Each partner learns and teaches more.
• Mutual code ownership enables a culture of code sharing.
Disadvantages
• Required both people to be available at once.
• More expensive to allocation two programmers per machine (customer my not like
it).
11. Code coverage
Listing 1: Branch coverage
1 i f (x > 5) {
2 print ( ’ a ’ ) ;
3
4 i f (x == 8) {
5 print ( ’b ’ ) ;
6 }
7
8 i f (x < 10) {
9 print ( ’ c ’ ) ;
10 }
11 else {
12 print ( ’d ’ ) ;
13 }
14 }
15 print ( ’ e ’ ) ;
(a)
6 Analyze the code fragment in Listing 1. Then, fill in the following table with the possible
combinations of output (via the print(...) call) and one possible value of x that will
cause it to happen. The first row has been filled in for you as an example.
Value of x Printed output
4 e
8 abce
5 < x < 10; x 6= 8 ace
x > 10 ade

12.
3 How would using a metrics tool like the one that we used in MP5 help you reverse engineer a
system? Pick one of the reverse engineering patterns that we cover in class and describe how
using a metrics tool would help.
Solution:
Refer to the relevant sections in A Pattern Language for Reverse Engineering
• Read all the code in one hour – To help focus on the important parts can use metrics
to identify suspicious code that score above the tolerated metrics threshold.
• Identify the Largest — The metrics tool reports the size of each entity and from this
you can infer the larger ones and concentrate your efforts on those.
13.
3 Software metrics are more useful as indicators of what’s wrong rather than what’s right about
a system. Explain.
Solution:
Software metrics should be used to determine which parts of your program might require
attention and fixing. If a part of the system scores a measurement beyond the recommended
threshold then you should investigate why that is and whether it needs to be fixed. On the
other hand, just because some part of the system is within the threshold of tolerance does
not mean that is right. It might have hidden problems that the metrics suite cannot detect
since metrics are calculated based on heuristics.
14. Depth of Inheritance Tree (DofIT)
(a)
2 Every class that you create in Java starts with a DofIT of 1. Answer true or false and
explain your answer.
Solution:
True. Every class in Java automatically inherits from Object.
Since the interpretation of the phrase starts with a DofIT of 1 might vary, other
answers with proper explanations were accepted as well.
(b)
2 Give a reason why is it desirable to keep the DofIT of a class low.
Solution:
The higher the DofIt of a class, the more methods it inherits. This makes it more
complex to reason about its behavior.

(c)
2 What is an example of a refactoring that could increase the DofIT of an existing class?
Solution:
Extract superclass (or a sentence describing the same procedure that this refactoring
does).
15. Kent Beck’s principles of simplest design
1. The system should have the fewest possible methods
2. The system (code and tests) must communicate everything you want to communicate
3. The system should have the fewest possible classes
4. The system must contain no duplicate code
(a)
2 Order the principles listed above in order of importance – from most important to least
important
(a)
Solution:
2, 4, 3, 1
(b)
4 Explain your decision for your choice of the most important principle and your choice for
the least important i.e. why did you list the principles is that order?
Solution:
2 as first: If the software doesn’t communicate what it doesn’t it is hard to know how
it works, and whether or not it works correctly.
1 as last: While it is important to keep the code simple and minimize the number of
methods, it is far more important to add methods whenever necessary to increase the
clarity and communicativeness of the code

16. In OO Design Quality Metrics, Robert Martin discusses a set of metrics for measuring the
quality of design in an object-oriented system.
Figure 1: Abstraction vs Instability Graph
(a)
2 According to Martin, what makes a design rigid? What kind of code smell does a rigid
design suffer from?
Solution:
A rigid design is one that is hard to change because making a single change would
entail making multiple changes in the related modules. A rigid design suffers from the
Shotgun Surgery or Non-localized Plan code smell.
(b)
2 Explain – in words without referring to Martin’s formulas – what makes a class stable.
Solution:
A stable class is one that does not depend on any other classes but has other classes
depending on it. Martin calls the former independence and the latter responsible.
(c)
2 Describe the category at position (0,0) in Figure 1 in terms of stability and abstraction.
Why is such a category not desired?
Solution:
The category at (0,0) is very stable but not abstract. It is not desired because its
stability makes it hard to change. And its concreteness makes it hard to extend. The
(0,0) location marks a design that is rigid.

(d)
2 Why is it desirable for a category to be as close as possible to the main sequence shown
in Figure 1?
Solution:
A category that is close to the main sequence is neither too abstract nor too instable.
Thus, it has the appropriate number of classes that depend on it (and an appropriate
number of classes that it depends on) to make maintenance easier. This is the kind of
design that object-oriented system should aim for.

17. Refactoring
Listing 2: Code with code smells
1 public int readStuff ( String fn ) throws IOException {
2 // Open a f i l e for read/ write (”rw”) access
3
4 RandomAccessFile f = new RandomAccessFile ( fn , ”rw” ) ;
5 f . seek (100); // Move to byte 100 of f i l e
6 byte [ ] bytes = new byte [ 1 0 0 ] ; // Create a b u f f e r to hold the data
7 f . read ( bytes ) ; // Read 100 bytes from f i l e
8 int i = f . readInt ( ) ; // Read a 4−byte integer from f i l e
9 f . seek (100); // Move back to byte 100
10 f . writeInt ( i ) ; // Write the integer f i r s t
11 f . write ( bytes ) ; // Then write the 100 bytes
12
13 i f ( i > 10000) {
14 f . c l o s e ( ) ;
15 return −1; // Return error code
16 }
17
18 i f ( i < 1234) {
19 f . seek (200); // Move back to byte 200
20 f . writeInt ( i ) ; // Write the integer f i r s t
21 f . write ( bytes ) ; // Then write 100 bytes
22
23 }
24
25 f . c l o s e ( ) ; // Close the f i l e
26 return 0; // Return no error
27
28 }
(a)
6 List three code smells that you detect in the Listing 2. It is acceptable to circle and use
arrows to point to the offending code segments. Use the name of the code smell. If you
do not remember the name simply do your best to describe the type of code smell.
Solution:
• Non-descriptive method name readStuff. The method both reads and writes.
• Non-descriptive variable names fn, f, bytes, i.
• Excessive comments. The comments are necessary because the code doesn’t
speak for itself.
• Magic numbers on lines 5, 6, 9, 13, 15, 18, 19 and 26.

• Code duplication: lines 9-11 with 19-21, and 14-15 and 25-26.
• Non-descriptive conditional statements on lines 13 and 18.
• Feature envy. The method send almost all of its method calls to the temporary
variable f.
(b)
8 Provide the refactored version of the code in Listing 2 that addresses the code smells that
you listed in part a).
Listing 3: Sample refactoring solution
1 public int rearrangeFile ( String fileName ) throws IOException {
2 MidtermFile f i l e = new MidtermFile ( fileName , ”rw” ) ;
3 return f i l e . rearrange ( ) ;
4 }
5
6 public class MidtermFile extends RandomAccessFile {
7 private static final int BUFFER SIZE = 100;
8 private static final int START OFFSET = 100;
9 private static final int SECOND OFFSET = START OFFSET ∗ 2;
10 private static final int LOWER VALUE = 1234;
11 private static final int MAXIMUMVALUE = 10000;
12 private static final int SUCCESS CODE = 0;
13 private static final int ERROR CODE = −1;
14
15 public MidtermFile ( String fileName , String mode)
16 throws FileNotFoundException {
17 super( fileName , mode ) ;
18 }
19
20 public int rearrange () throws IOException {
21 seek (START OFFSET) ;
22 byte [ ] buffer = new byte [BUFFER SIZE ] ;
23 read ( buffer ) ;
24 int numberToMove = readInt ( ) ;
25 seekAndWrite (START OFFSET, buffer , numberToMove ) ;
26 i f ( needsDuplication (numberToMove )) {
27 seekAndWrite (SECOND OFFSET, buffer , numberToMove ) ;
28 }
29 c l o s e ( ) ;
30 i f ( isAboveMax (numberToMove )) return ERROR CODE;
31 return SUCCESS CODE;
32 }
33
34 private boolean needsDuplication ( int value ) {
35 return value < LOWER VALUE;
36 }

37
38 private boolean isAboveMax ( int value ) {
39 return value > MAXIMUMVALUE;
40 }
41
42 private void seekAndWrite ( int o f f s e t ,
43 byte [ ] buffer , int number)
44 throws IOException {
45 seek ( o f f s e t ) ;
46 writeInt (number ) ;
47 write ( buffer ) ;
48 }
49
50 }
Page 12 of 12 End of exam.

midterm_fa07.pdf

More Related Content

Similar to midterm_fa07.pdf (20)

More from RavinderKSingla (20)

Recently uploaded (20)

midterm_fa07.pdf