Answers to SEG 2100 Midterm 1998 Note that material covered during 1998 was a bit different from subsequent versions of the course. This is because in 1998, students knew no java upon entering the course. The most difficult question was the programming question number 12). The class was clearly split between those who didn't get it (generally less than 10/25) and those who did (greater than 20/25), with very few in between. It looks like some group members are 'going along for the ride' when it comes to the labs. If your mark was less than 15/25 for this question, you should put extra work into the labs and assignments otherwise you will have a very hard time in the final exam. In particular, you should work through an on-line Java tutorial, and practice writing simple java classes. ----- Q1. Answer c. Class average 2.3 out of 3 Q2. Answer c. Class average 3 out of 3 Q3. Answer c. Class average 2.8 out of 3 Q4. Answer a; one point for f. Class average 1.1 out of 3 - Connection to client could have been designed to be observable, but is not. Q5. Answer e. Class average 2.5 out of 3 Q6: The biggest problem was that people omitted key points. You didn't have to get all the points, but you should have got most to get 10/10. Class average 8.3/10 Answer - Software deterioration is the reduction in maintainability and increase in the number of defects and in usefulness as software ages. This means that the software is increasingly expensive to maintain and becomes less able to solve the customers' problems. - Major contributors to deterioration include: a) Changes made to the software or to fix bugs that do not fit with the original design, often because the original requirements and design had not anticipated them or was poorly done; b) People making changes without adequate skill; c) People making changes without following effective software engineering process. - To solve: Perform better original requirements analysis; design for flexibility; use skilled people; follow a good SE process; re-engineer poor parts of the software Q7: Some people listed all risks, when I was interested only in requirements ones. Class average 7.9/10 Answer: - Major risks: Not understanding the problem (by software engineer and client); misunderstanding the user's vocabulary; changing requirments; developing requirements and software when software is not really necessary; the client not understanding what can be done by software - Solutions: Take plenty of time gathering and analysing requirements; use the client's language; use a variety of techniques such as brainstorming, interviewing etc.; continue to work on requirements over the lifetime of the software; think about the software's lifespan and potential future requirements; be aware that requirements will definitely change. Q8: Class average 7.9/10 Answer - Validation is "doing the right thing", i.e, solving the customer's problem; verification is "doing the thing right", i.e. sticking to the good requirement, design etc. (whatever was planned in the previous stages). At the end of any step in the software engineering process, we must ensure that we are doing both these things, otherwise we must go back to the previous stage. Q9: Class average 9.2/10 Answer - Encapsulation involves hiding details behind a well-defined interface. This allows us to separate the system into components that different people can work on (without having to understand the internals of components they are merely using). This reduces complexity, increases reliability and permits faster development and reuse of components. Q10: The main problem here was confusion with the Observer class. Threads can be observers, but do not have to be. Class average 8.5/10 Answer - To use threads, you must: a) Create a runnable class (either a subclass of Thread, or an implementor of the Runnable interface). b) Write a run method in the new class (this will normally loop, doing something repeatedly, and typical waiting for input each time round the loop). c) Call start to start the thread. Q11: Class average 18.4/20. This was the best-done question. Answer The most important actors are - The person who calls and leaves a message - The person who receives the messages - I accepted as an actor the answering machine -- an autonomous agent that takes messages - The biggest problems with this part were: - Missing actors - Being too vague (person) - Extraneous actors (e.g. telephone) The biggest problems with your list of use cases were: - use cases that did not describe something the actor does with the system - use cases that did not belong in this system - no description, or description doesn't describe the step-by-step process - not specifying which actor does which use case Q12: Class average 18.4/25 The answer follows at the end -- this is the simplest possible answer that would have got you 25/25. Key problems: - Not understanding what constructors and instance variables are. e.g. putting instance variables as local variables or vice versa. - using System.out.println in the toString() method - Not putting executable statements in methods - Thinking that the '<' and '>' characters in the format should be printed out You will see 6 numbers for this question. 5 marks for basic class structure and syntax 5 marks for instance variables 5 marks for constructors 5 marks for toString() 5 marks for getAreaCode() 25 marks total The answer below is one possible answer. A completely alternative design done by a couple of students would have been to store the phone number as a single String instance variable. ----- public class NorthAmerPhoneNumber { // Minimal answer to SEG 2100 Midterm question 12 // Instance variables private int areaCode, prefix, number, extension; // Constructors NorthAmerPhoneNumber(int ac, int pre, int num, int ext) { // You might have done some validation here to ensure that the // number of digits is valid; however I didn't require it areaCode = ac; prefix = pre; number = num; extension = ext; } NorthAmerPhoneNumber(int ac, int pre, int num) { areaCode = ac; prefix = pre; number = num; extension = 0; } // Instance methods public String toString() { if(extension == 0) return toString1(); else return toString1() + " x" + extension; } private String toString1() { // Notice that I write this in a separate method to avoid // Duplicating it in the toString method return "(" + areaCode + ") " + prefix + "-" + number; } public int getAreaCode() { return areaCode; } // You didn't need to write this. However I have provided it // So that you can actually compile and run this class public static void main(String argv[]) { System.out.println(new NorthAmerPhoneNumber(613,237,6642)); System.out.println(new NorthAmerPhoneNumber(613,562,5800,6685)); System.out.println(new NorthAmerPhoneNumber(613,237,6642).getAreaCode()); } }