SlideShare une entreprise Scribd logo
1  sur  15
Télécharger pour lire hors ligne
________________________________ _________________________________ _________________________________
NAME ID SIGNATURE
Department of Electrical and Computer Engineering, McGill University
ECSE 321 - Introduction to Software Engineering
Final Examination
December 12, 2002, 2:00pm-5:00pm
−−−−ANNOTATED SOLUTIONS−−−−
Examination version 1
Prof. Radu Negulescu
Associate examiner:
INSTRUCTIONS
• Write your name, McGill student ID number, and signature in the following places: the cover of the
answer booklet, the computer sheet enclosed, and the top of this page. Fill in the corresponding circles on
the computer sheet.
• Write the examination version number from the box above to the computer sheet enclosed, and fill in the
corresponding circle.
• This examination consists of two sections: section I consists of 15 multiple-choice questions; section II
consists of 4 essay-type questions. Section I is worth 30 marks in total; section II is worth 135 marks in
total. The multiple-choice questions are equally weighted; invalid or omitted answers are worth 0 marks.
Question 4 of section II offers a choice of two parts, of which you should attempt only one part.
• Use pencil only to fill your answers to the multiple-choice questions in the enclosed computer sheet.
• Write your answers to the essay-type questions in the separate answer booklet provided. Draw a diagonal
line over each scratch sheet in the answer booklet; scratch sheets will not be marked.
• This examination booklet has 8 pages, including this page. Keep all pages together.
Good luck!
Page 2
SECTION I – MULTIPLE-CHOICE QUESTOINS
USE PENCIL ONLY TO FILL ANSWERS IN THE COMPUTER SHEET
EACH VALID ANSWER GETS 2 MARKS, EACH INVALID OR OMITTED ANSWER GETS 0 MARKS
Question 1. Consider the following requirement for a spreadsheet program: “The product shall not offer search
and replace options that could have disastruous results.” This requirement is flawed mainly because:
(a) It is not feasible.
(b) It has implementation bias.
(c) It says what the product shall not do instead of what the product shall do.
(d) It is ambiguous.
(e) No specific reason.
Question 2. Consider a system consisting of a client module that passes flags to server modules to indicate which
operations should be performed by the server modules. This system has:
(a) Unacceptably loose coupling.
(b) Unacceptably weak cohesion.
(c) Unacceptably tight coupling.
(d) Unacceptably strong cohesion.
(e) Acceptable but not perfect cohesion and coupling.
Question 3. Which of the following statements is true?
(a) There is no need to insert breakpoints at every line of code because the “step over” debugger function
can achieve the same effect more easily.
(b) Good programmers don’t need to use advanced debugger features for increased efficiency if they use
assertions to think about the code.
(c) Good programmers don’t need to use assertions to think about code if they know how to use powerful
debugger features.
(d) All of the above.
(e) None of the above.
Question 4. An advantage of sandwich testing over modified sandwich testing is:
(a) Sandwich testing has more coverage.
(b) Sandwich testing has fewer test cases.
(c) Sandwich testing has fewer test drivers.
(d) Sandwich testing has fewer precedence dependencies between test cases. (as shown during the lectures)
(e) None of the above.
Question 5. An advantage of active design reviews versus Fagan inspections is:
(a) Reducing the number of meetings needed.
(b) Helping the author to fix the defects found by suggesting how to fix the defects.
((b) is wrong because Parnas’s “active design reviews” are a type of inspection)
(c) A better use of reviewer time by eliminating the general meeting.
(d) All of the above.
Page 3
(e) None of the above.
Question 6. The MAIN benefit of performing unit testing before integration or system testing in a large project
with high quality requirements is:
(a) To save effort in locating defects. (true, but not nearly the most compelling benefit)
(b) To save effort in finding failures by easier targeting of test cases to coverage criteria for individual units.
(c) To satisfy the customer requirements. (those would be covered by system tests)
(d) To disseminate the corporate culture.
(e) All of the above.
Question 7. Which of the following prototypes is LEAST likely to be needed for clarifying the non-functional
requirements of the software controller for a cellular phone:
(a) A prototype for reception of signals from the phone branch exchange.
(b) A prototype for transmission of signals to the phone branch exchange.
(c) A prototype for performance tuning using calibrated stubs.
(d) A broad prototype, including transmission, reception, and user interface. (“spike solutions”…)
(e) A user interface mock-up with the capability of collecting usage statistics.
Question 8. Which of the following statements is true for nearly all software development projects:
(a) Unit testing must be completed before integration testing can start. (unit testing overlaps integration)
(b) There should be a high-level architecture phase. (not in XP)
(c) Every non-functional requirement must be tested.
(d) Modified sandwich testing is the best integration testing strategy.
(e) All of the above.
Question 9. Which of the following statements makes inadequate use of the terms process, project, or product:
(a) My web-based project has sub-second response time.
(b) The process in our company is quality-oriented.
(c) Our product has high reliability.
(d) Software projects tend to progress more slowly as they get closer to the release deadline.
(e) None of the above.
Question 10. Which of the following statements is a reasonable assumption for a typical software project:
(a) The probability of failure-free operation is the mean time to failure.
(b) The mean time to failure in using a feature is proportional with the number of defects in that feature.
(c) The mean time to failure in using a feature is inversely proportional with the number of defects in that
feature.
(d) All of the above.
(e) None of the above.
Page 4
Question 11. Which of the following process models is LEAST adequate for implementing the software for an
embedded safety belt controller, and what is a reason for the inadequacy:
(a) The waterfall model, because the requirements are not well understood.
(b) The spiral model, because there are no major risks involved.
(c) The V model, because very few tests need to be carried out.
(d) The prototyping model, because there is no need for prototypes in this project.
(e) The incremental and iterative model, because the controller function cannot be easily split into
increments.
Question 12. Which of the following process models is MOST adequate for starting a new business in network
server firewalls together with your friends, and why:
(a) The V model, because it allows more parallelism in development than waterfall.
(b) Extreme programming, because it does not have a high-level architecture phase.(close choice, but very bad reason
- actually this is a reason why XP is probably not the wisest choice for a project that requires well-
thought design of uniform security policies at the system/architecture level)
(c) The prototyping model, because requirements are not well understood beforehand.
(d) The sharktooth model, because it includes demos of prototypes to the management.
(e) The waterfall model, because requirements analysis needs to be performed before writing code.
Question 13. Which of the following can NOT be a review criterion for high-level design:
(a) Feasibility.
(b) Checking whether the static data models are consistent with scenarios of normal usage.
(c) Checking whether the static data models are consistent with scenarios of user errors.
(d) Absence of implementation bias. (design is always implementation-biased)
(e) Security properties.
Question 14. Which of the following statements is FALSE:
(a) Cyclomatic complexity gives the exact number of test cases needed for complete branch coverage.
(b) An upper bound for the minimum number of test cases needed for complete branch coverage can be
computed by counting certain keywords in a piece of code.
(c) An upper bound for the minimum number of test cases needed for complete statement coverage can be
computed by counting certain keywords in a piece of code.
(d) If N is the number of nodes and E the number of edges in a flow graph, the cyclomatic complexity of that
flow graph is N – E + 2.
(e) The cyclomatic complexity of a flow graph is independent of the inclusion or exclusion of nodes for
assignment statements in the flow graph.
Page 5
Question 15. Consider the following Java method, whose flow graph is shown below:
public static int getNumDaysInMonth(int month, int year)
throws MonthOutOfBounds, YearOutOfBounds {
int numDays;
if (year < 1) {
throw new YearOutOfBounds(year);
}
if (month == 1 || month == 3 || month == 5 || month == 7 ||
month == 10 || month == 12) {
numDays = 32;
} else if (month == 4 || month == 6 || month == 9 ||
month == 11) {
numDays = 30;
} else if (month == 2) {
if (isLeapYear(year)) {
numDays = 29;
} else {
numDays = 28;
}
} else {
throw new MonthOutOfBounds(month);
}
return numDays;
}
[ y e a r < 1 ]
[ m o n t h i n ( 1 , 3 , 5 , 7 , 1 0 , 1 2 ) ]
n = 3 2
t h r o w 2 n = 2 9
r e t u r n
t h r o w 1
n = 2 8
n = 3 0
[ m o n t h i n ( 4 , 6 , 9 , 1 1 ) ]
[ m o n t h = = 2 ] [ l e a p ( y e a r ) ]
The minimum number of test cases needed for complete STATEMENT coverage of the method above is:
(a) 14 (the right answer for branch coverage)
(b) 6 (the right answer for statement coverage)
(c) 5
(d) 4
(e) None of the above.
Page 6
SECTION II – ESSAY-TYPE QUESTIONS
WRITE YOUR ANSWERS IN THE ANSWER BOOKLET
Question 1. (requirements, modeling, testing)
You are developing the software controller for a vending machine that makes coffee. The machine has a slot for
inserting coins, a button for change return, and three buttons for selecting the coffee: Espresso, Cappuccino, and
Latte. The machine also has a boiler and a nozzle for delivering the coffee, an output slot for returning the change,
and a display for displaying the status of the interaction with the user: amount of money received, steps of making
the coffee, error messages, etc.
The vending machine operates as follows. The customer inserts coins up to the amount of $1.25, which is the
price of a cup of coffee. The machine accepts only quarters and one-dollar coins (loonies). If the amount is
exceeded or the coins have the wrong values, the extra coins are immediately returned. For example, if two one-
dollar coins are inserted consecutively, the second coin is returned; if six quarters are inserted, the sixth is returned.
Immediately following the insertion of each coin, the display confirms the total amount of money received so far.
In parallel, the customer selects the coffee desired. If the selection is made after the full amount is inserted, the
vending machine makes the coffee and delivers it through the nozzle. If the change return button is pressed before
the coffee is made, the money is returned. Throughout the operation cycle, the display is used to acknowledge
each user action by indicating the status of the interaction. After the coffee is delivered, the vending machine
repeats the operation cycle above.
The controller of the vending machine senses and actuates the hardware by invoking methods of a hardware driver
object, as follows:
• coinInserted(int coin) executes on each insertion of a coin, with parameter coin set to 25 for a quarter and
100 for a loonie;
• changeButtonPressed() executes on each push of the change return button;
• selectionButtonPressed(String choice) executes on each push of a coffee selection button, with parameter
choice set to “Espresso”, “Cappuccino”, or “Latte”, indicating which button has been pressed;
• display(String message) outputs the message string on the display;
• makeCoffee(String choice) activates the boiler and nozzle to deliver the coffee according to the value of
parameter choice;
• returnCoin(int coin) returns a quarter if parameter coin is 25 and a loonie if coin is 100.
The controller for the vending machine has to be developed according to the DEFENSIVE PROGRAMMING
paradigm.
(a) Draw a use case diagram for the vending machine controller. Be sure to identify all the main use cases,
actors, and their relationships. [5 marks]
(b) Draw a state chart describing the behavior of the controller as seen at the interface between the controller
and the hardware driver object, i.e., in terms of invocations of the methods above. Use nesting and
concurrency to simplify the state chart. [20 marks]
(c) Specify a set of test cases that ensures complete transition coverage of the state chart in Part (b).[10 marks]
(d) Briefly explain the main reasons for and against using complete transition coverage of a hierarchical state
chart as the coverage criterion for testing the vending machine controller (no more than 3 reasons total,
one sentence each). [5 marks]
Page 7
(a)
Coffee
selector
Money
insert
Coffee
output
Make coffee
Refund change on request
Refund extra change
<<extends>>
<<extends>>
Display
watcher
(b)
cBP() /
rC(25),
rC(100)
cI(25)/rC(25),d(25)
cI(100)/rC(100),d(100)
SelectCoffee
on entry:
d(“Cap.
selected”)
on entry:
d(“Lat.
selected”)
on entry:
d(“Esp.
selected”)
on entry:
d(“Please select
coffee”)
sBP(“Cap.”)
sBP(“Esp.”)
sBP(“Lat.”)
on entry: d(0) cI(100)/d(100)
cI(25).
/d(125)
InsertChange
cI(100)/
rC(100),
d(50)
cI(25)/d(75)
/ mC(“Cap.”)
/ mC(“Esp.”)
/ mC(“Lat.”)
on entry:
d(“Making Cap.”)
on entry:
d(“Making Esp.”)
on entry:
d(“Making Lat.”)
MakingCoffee
cBP() / d(“Refund expired”)
cI(25) / rC(25), d(0)
cI(100) / rC(100), d(0)
sBP(anyString) / d(“Please wait”)
H
after 2 seconds
on entry:
d(“Thanks!”)
cI(25)/d(50)
cI(25)/d(25)
cI(100)/d(125)
cBP()
cBP()/rC(25)
cBP()/
rC(25),rC(25)
cBP()/rC(25),
rC(25),rC(25)
cBP() /
rC(100)
cI(100)/d(100)
cI(100)/
rC(100),
d(75)
cI(100)/rC(100),d(125)
cI(25)/rC(25),d(125)
cI(100)/
rC(100),
d(100)
Page 8
Notes:
- The “Thanks” note and “after 2 sec” transition at the end of the cycle are not marked, but the need for them could
be inferred from the requirement to display the status of the interaction - specifically, the need to inform the user
that the cycle has been completed.
- The history pseudostate, marked (H), means that re-entry to the “Making Coffee” superstate is through the last
visited substate, or to the “Thanks” state if this si the first entry. Use of the history pseudostate is off the scope of
the exam and therefore not marked; the solution can be completed without a history pseudostate, by moving the
self-loop from Making Coffee to the substates of Making Coffee and replacing the (H) by a usual initial state.
(c)
Test insertions: insert the required amount in the three possible ways
cI(100); d(100); cI(25); d(125)
cI(25); d(25); cI(100); d(125);
cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125);
Test change return on request: go to each state, request return
cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); cBP(); rC(100); rC(25); d(0)
cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cBP(); rC(100); d(0)
cI(25); d(25); cI(25); d(50); cI(25); d(75); cBP(); rC(25); rC(25); rC(25); d(0)
cI(25); d(25); cI(25); d(50); cBP(); rC(25); rC(25); d(0)
cI(25); d(25); cBP(); rC(25); d(0)
Test extra change return: go to 4 states, insert a loonie, get it back; go to last state, insert a quarter, get it back
cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); cI(100); rC(100); d(125)
cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(100); rC(100); d(100)
cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(100); rC(100); d(75)
cI(25); d(25); cI(25); d(50); cI(100); rC(100); d(50)
cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); cI(25); rC(25); d(125)
Test coffee making:
sBP(“Cap.”); d(“Cap.”); cI(100); d(100); cI(25); d(125); mC(“Cap”); d(“making Cap.”); d(“Thanks”)
sBP(“Esp.”); d(“Esp.”); cI(100); d(100); cI(25); d(125); mC(“Cap”); d(“making Esp.”); d(“Thanks”)
sBP(“Lat.”); d(“Lat.”); cI(100); d(100); cI(25); d(125); mC(“Lat”); d(“making Lat.”); d(“Thanks”)
Test invalid user actions during coffee making:
sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) cPB() d(“Refund expired”)
sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) cI(25) rC(25) d(0)
sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) cI(100) rC(100) d(0)
sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) sBP(anyString) d(“Pls. wait”)
(d)
Reasons for:
- avoids explosion of the number of test cases by avoiding explosion of the number of states and transitions
- test cases (targeted to nested/concurrent superstate transitions) map well to independent functional requirements
Reasons against:
- does not target boundary cases (such as requesting change refund with no credit) which have a rich concentration
of defects
- does not cover all combinations of concurrent states / interleavings of threads of control, which may trigger
desirable events (such as making Cappuccino coffee) as well as undesirable events
- does not target internal states and transitions (a black-box rather than structural technique)
- such test cases might be difficult to run if they rely on relative timing of the user and multiple threads of control
Page 9
Marking:
Any two of the above will do.
Question 2. (design)
You are developing a task management program for a company. The program allocates the company staff to tasks
in a way that satisfies the workload constraints of every person in the staff. Each person has constraints on the
maximum number of tasks that person can perform at any given time, and this number may vary every week.
Tasks may contain sub-tasks, but a sub-task cannot be part of several tasks. Staff is grouped in teams; teams are
grouped in departments; departments are grouped in business units. Teams may overlap, i.e., the same person can
be a member of several teams. Department and business units may overlap, too.
Draw the class diagram for a high-level design model of the task management program. Discuss your main design
decisions with respect to the modularity / performance tradeoff (bulleted list form, maximum 5 decisions,
maximum 3 lines of explanation per decision). Hint: try to achieve a simpler design by offering a more uniform
functionality (as discussed during the design lectures). [30 marks]
TaskEntry
UI
*
BasicTask CompositeTask
0..1
GroupEntry
*
Person Group
*
BUnitTeam DepartmentConstraint
array[week] of taskLimit
Allocation
array of week
AllocationCtrl
specifyTaskSet(crtTaskSet)
Allocation allocate()
* *
Company
1
crtTaskSet
allocationResult
*
create
specifyTaskSet
allocate
*1
1
*
1 1
1
*
Design decisions:
1. Use the Composite pattern to represent tasks:
- Decouples handling of basic tasks from maintaining lists of tasks.
- Blends well with the needs of inputting a task set.
- Little or no performance cost – traverse just one reference to go through a level of the task tree.
2. Use the Composite pattern to generalize the company hierarchy structure.
- It is a more uniform design than a specific department structure – easier to develop, test, extend.
- Little or no performance cost – just one reference to go through a level of the groups hierarchy.
3. Allow allocation of hierarchical tasks to hierarchical groups instead of individual persons.
- More functionality for no extra complexity.
Page 10
4. One control object for each allocation:
- Easy to maintain by decoupling consecutive allocations; e.g.threading can be done with minimal impact.
- Costs for creation and destruction of objects.
Note:
Any good solution to this question should abstract the similarities of team, department, business unit, into a
superclass (“group”). The decoupling tradeoffs discussed during the first lecture on patterns naturally lead to the
composite pattern, which allows any number of levels of the hierarchy. Therefore any good solution offers
slightly more functionality with a simpler and more uniform design! A simpler, more uniform design is easier to
code, test, maintain, etc. Such is the essence of good software design.
Question 3. (analysis, assertions, testing)
You are developing a web-based reservation system for a university computer laboratory. The system maintains a
daily reservation schedule that consists of 8 one-hour time slots for each workstation in the laboratory. Each
semester, each student can reserve up to 100 time slots on individual laboratory workstations. The reservations
can be made or retracted at least one day in advance, at any time. To make or retract a reservation, a student
accesses the URL of the reservation system, logs in using his or her name and ID, and selects or deselects slots by
clicking on the slots in the schedule. On login, the system shows the number of remaining hours to be reserved by
the respective student; that number decrements on each selection and increments on each deselection. A student
can only deselect slots that are currently reserved by that student, and can only select slots that are not currently
reserved by any student.
(a) Draw a class diagram for an analysis model of the web-based reservation system. [10 marks]
(b) Assuming the design-by-contract paradigm is used at the user interface of the reservation system, specify
the pre- and post-conditions for selecting a time slot and for de-selecting a time slot. [10 marks]
(c) Assuming the defensive programming paradigm is used at the user interface of the reservation system,
specify the pre- and post-conditions for selecting a time slot and for de-selecting a time slot. [10 marks]
(d) Assume the system stores references to students who made the reservations, indexed by time slot and
workstation number, or null references for free slots; and, the system stores the remaining number of hours
for each student. Specify the invariants on the data structure of the reservation system. [10 marks]
(e) Derive a comprehensive set of black-box tests for the operations of selecting and deselecting time slots
described above. [10 marks]
NOTE: Each of the assertions in Question 3 (b), (c), (d) (or (a) if needed) may be specified using mathematical
logic, OCL, unambiguous natural language, or combinations thereof.
Page 11
(a)
Constraint:
forall StudentInfo s:
s.hoursLeft +
#{slot: slot.student = s}
= 100
serverObject
URLAccessed
ReservationCtrl
login(name, ID)
select(crtSlot)
deselect(crtSlot)
create
*1
ClientUIForm
display
mouseClicked
sendLogin
sendCommand
1
login
command
*1
create
* 1
*
StudentLog
check(name, ID)
addStudent
deleteStudent
check
1*
StudentInfo
name, ID
hoursLeft
incrementHours()
decrementHours()
crtStudent
1*
1
*
ReservationLog
StudentInfo check(slot)
reserve(slot, student)
unreserve(slot)
check
reserve
unreserve
1*
ReservationSlot
day, time
workStation
StudentInfo check()
setStudent (student)
crtSlot
1*
1
*
0..1
0..100
Timer
day
time
getCrtTime
getCrtTime
1 *
if (timer.getCrtTime is at least one day before time
and reservationLog.check(slot) indicates a free slot
and crtStudent.getHoursLeft > 0)
crtSlot.setStudent(crtStudent)
crtStudent.decrementHours()
// else, do nothing
if (timer.getCrtTime is at least one day before time
and reservationLog.check(slot) == crtStudent)
crtSlot.setStudent(free/null)
crtStudent.incrementHours()
// else, do nothing
(b) – design by contract
Select:
Pre: crtStudent.hoursLeft > 0 && crtSlot.student == null && time – getCrtTime >= 1 day
(&& in-range studentID, reservation day, reservation time slot, workstation number)
Post: crtSlot.student' == crtStudent && crtStudent.hoursLeft' = crtStudent.hoursLeft – 1
Deselect:
similar
Marking:
Select: Pre: check hours credit / 1, free slot / 1, current time / 1; Post: make reservation / 1, update hours / 1
Deselect: Pre: check owned slot / 2, current time / 1; Post: undo reservation / 1, update hours / 1
(c) – defensive programming
Select:
Pre: crtStudent.hoursLeft > 0 && crtSlot.student == null && time – getCrtTime >= 1 day
(&& in-range studentID, reservation day, reservation time slot, workstation number)
Page 12
Post:
if crtSlot.student' == crtStudent && crtStudent.hoursLeft' = crtStudent.hoursLeft – 1
else crtSlot.student' == crtSlot.student && crtStudent.hoursLeft' = crtStudent.hoursLeft
in words, if pre is satisfied then the results are correct; if pre is not satisfied then do no updates.
OR, equivalently,
Pre: none (defensive programming)
Post:
if (crtStudent.hoursLeft > 0 && crtSlot.student == null && time – getCrtTime >= 1 day)
crtSlot.student' == crtStudent && crtStudent.hoursLeft' = crtStudent.hoursLeft – 1
else
crtSlot.student' == crtSlot.student && crtStudent.hoursLeft' = crtStudent.hoursLeft
Deselect:
similar
(d) – invariants
TOTAL HOURS = 100 / 5 marks
forall students s:
s.hoursLeft + #slots reserved by s == 100
LIMITS / 3 marks
forall students s:
s.hoursLeft is in 0..100; and #slots reserved by s is in 0..100
OTHER / 2 marks – at least one from the list
forall reservation slots r:
r.student is either a the reference of a student object or equal to the null reference
unique ID for each student
unique workstation ID
limits on the # of slots
etc.
(e) – black-box tests
Assumptions:
- Since selection/deselection is done by clicking on a posted schedule, only in-range days, timeslots and
workstation numbers are tested.
- Since selection/deselection follows login, only valid student IDs are tested.
Page 13
Input Output
Test # Description studentID hrsLeft time-crt time-slot slot status hrsLeft slot status
sel.eq.1 Select free slot 1234 38 3/day14 5/day22 free 37 res.1234
sel.eq.2 Select slot owned by other 1234 38 3/day14 5/day22 res.5678 38 res.5678
sel.eq.3 Select same day 1234 38 3/day14 3/day14 free 38 free
sel.eq.4 Select <24hrs next day 1234 38 3/day14 2/day15 free 38 free
sel.eq.5 Select with no hours left 1234 0 3/day14 5/day22 free 0 free
sel.bd.1 Select slot owned by oneself 1234 38 3/day14 5/day22 res.1234 38 res.1234
sel.bd.2 Select first day 1234 100 1/day0 3/day1 free 99 res.1234
sel.bd.3 Select last day 1234 12 3/day5 3/day100 free 11 res.1234
sel.bd.4 Select first slot 1234 12 3/day5 1/day22 free 11 res.1234
sel.bd.5 Select last slot 1234 12 3/day5 8/day22 free 11 res.1234
sel.bd.6 Select exactly 24h before 1234 12 3/day5 3/day6 free 11 res.1234
sel.bd.7 Select with one hours left 1234 1 3/day14 5/day22 free 0 res.1234
sel.bd.8 Select with all hours left 1234 100 3/day14 5/day22 free 99 res.1234
EQUIVALENCE TESTS - SELECT OPERATION
BOUNDARY TESTS - SELECT OPERATION
Deselect test cases: similar
Notes:
- It is very important to give specific numbers for inputs and expected outputs, to reproduce the tests and failures.
- Other good test cases might be:
Select and deselect a slot immediately, and with some other operations in between.
Click outside schedule, on the table border, on a border between two slots.
Question 4.
This question has two parts, of which only one will be marked: either the whole of Part A only, or the whole of
Part B only. To obtain credit, indicate clearly in the answer booklet which part you want marked.
PART A. (guest lecture)
(a) Give two specific examples of dangers entailed when code with inadequate speed optimizations is
installed on a different platform. [5 marks]
(b) Give two examples of programming guidelines that will help avoid the dangers above. Be sure to actually
indicate how following the guidelines will avoid the specific dangers mentioned (one sentence per
guideline). [5 marks]
(c) Briefly explain three main advantages of choosing software engineering as a career, and two main
challenges that arise in practicing software engineering in the industry (one sentence each). [5 marks]
PART B. (reliability)
Estimate the initial number of faults and the number of defects on release for a software project whose number of
faults found per week of quality assurance is as plotted in Figure 1. Assume the software is released on week 15.
Assume an exponential reliability growth model as shown by the “interpolated” curve. Show your work by
indicating the basis for your calculations. [15 marks]
Page 14
QA week #
(normalized)1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Faults found
(log scale)
interpolated
101
102
103
100
Figure 1. Number of faults found during each week of quality assurance in a software project.
Part A.
(a)
Dangers (based on guest lecture - many variations are accepted):
(1) Segmentation fault when a routine marks the end of the loop by overwriting protected memory used for input.
(2) Unpredictable hardware effects when a routine demarcates input data by overwriting I/O mapped memory
used for input.
(b)
Guidelines (many variations are accepted):
(1) Write for people, not for machine: keep code simple, standard style.
(2) Document preconditions; include any assumptions regarding pointers to writable memory. This will make
compulsory that clients of the routine do not pass pointers to protected or I/O mapped memory for memory areas
that need to be writable.
(3) Keep right attitude: don’t just be happy when code seems to work, but be sure you know why/how it works;
step through new code at least once; this will reduce exposure if the problems above are in someone else’s code
(4) Turn on all compiler warnings: writing outside memory may be flagged as such
(c)
Advantages (any 3 will do):
- portable profession: can apply it in a wide range of industries, geographical areas, etc.
- wide range of applications: potential of being helpful for diverse types of problems: commercial, medical, etc.
- shorter completion cycles: get to see your creations deployed and used
- closeness to application: deal with concepts from the problem domain rather than 0/1 abstractions
Challenges (any 2 will do):
- working with or reporting to non-technical people: frictions due to different expectations and attitudes
- dealing with legacy code: hampered by incomplete understanding, bad coding practices of the past
- geographical and cultural boundaries: development of a system is distributed around the world
Page 15
Part B.
Let:
N0 = initial number of faults
Nrelease = number of faults on release
N(t) = number of faults at time t
W(t) = faults found during week t
From model:
W(t) = N0 f(t) = N0 f0 e^(-t f0)
=> log_10(W(t)) = log_10 (N0 f0) – f0 t / 2.3
=> f0 / 2.3 = slope of W(t) line on log scale = 1.5 / 15 = 0.1
=> f0 = 0.23 / 5
Also from model:
N(t) = N0 (1 – F(t)) = N0 e^(-t * f0) = W(t) / f0
N0 = N(0) = W(0) / f0 =~ 10^2.5 / 0.23 =~ 1375 / 5
Nrelease = N(15) = W(15) / f0 =~ 10 / 0.23 =~ 43 / 5
Notes:
- Sanity check:
The sum of the number of defects found each week should be N(0) - N(15) = 1332.
The actual sum is approximately 2500 – close enough for a ballpark estimate.
- In practice, reconcile the estimates: eliminate the garbled points and/or adjust the interpolation until they agree,
as in Figure 2
- On the new estimates, f0 = 2.3 * 2/15 = 0.3; N0 = W(0)/f0 = 1000/0.3 = 3333; Nrelease = 10/0.3 = 33.
Although N0 changes a lot (2.5x), Nrelease stays close to the original estimate (23%),
so the method is pretty good at finding the number of defects on release.
QA week #
(normalized)1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Faults found
(log scale)
interpolated
101
102
103
100
Figure 2. Adjusted interpolation.

Contenu connexe

Tendances

Software Defect Prediction on Unlabeled Datasets
Software Defect Prediction on Unlabeled DatasetsSoftware Defect Prediction on Unlabeled Datasets
Software Defect Prediction on Unlabeled DatasetsSung Kim
 
Metamorphic Security Testing for Web Systems
Metamorphic Security Testing for Web SystemsMetamorphic Security Testing for Web Systems
Metamorphic Security Testing for Web SystemsLionel Briand
 
A Tale of Experiments on Bug Prediction
A Tale of Experiments on Bug PredictionA Tale of Experiments on Bug Prediction
A Tale of Experiments on Bug PredictionMartin Pinzger
 
The adoption of machine learning techniques for software defect prediction: A...
The adoption of machine learning techniques for software defect prediction: A...The adoption of machine learning techniques for software defect prediction: A...
The adoption of machine learning techniques for software defect prediction: A...RAKESH RANA
 
ESTIMATING HANDLING TIME OF SOFTWARE DEFECTS
ESTIMATING HANDLING TIME OF SOFTWARE DEFECTSESTIMATING HANDLING TIME OF SOFTWARE DEFECTS
ESTIMATING HANDLING TIME OF SOFTWARE DEFECTScsandit
 
Continuous test suite failure prediction
Continuous test suite failure predictionContinuous test suite failure prediction
Continuous test suite failure predictionssuser94f898
 
Scalable Software Testing and Verification of Non-Functional Properties throu...
Scalable Software Testing and Verification of Non-Functional Properties throu...Scalable Software Testing and Verification of Non-Functional Properties throu...
Scalable Software Testing and Verification of Non-Functional Properties throu...Lionel Briand
 
Analyzing Changes in Software Systems From ChangeDistiller to FMDiff
Analyzing Changes in Software Systems From ChangeDistiller to FMDiffAnalyzing Changes in Software Systems From ChangeDistiller to FMDiff
Analyzing Changes in Software Systems From ChangeDistiller to FMDiffMartin Pinzger
 
Can we predict the quality of spectrum-based fault localization?
Can we predict the quality of spectrum-based fault localization?Can we predict the quality of spectrum-based fault localization?
Can we predict the quality of spectrum-based fault localization?Lionel Briand
 
June 2010 exam questions and answers
June 2010   exam questions and answersJune 2010   exam questions and answers
June 2010 exam questions and answersDamonTauroa
 
A practical guide for using Statistical Tests to assess Randomized Algorithms...
A practical guide for using Statistical Tests to assess Randomized Algorithms...A practical guide for using Statistical Tests to assess Randomized Algorithms...
A practical guide for using Statistical Tests to assess Randomized Algorithms...Lionel Briand
 
Testing Machine Learning-enabled Systems: A Personal Perspective
Testing Machine Learning-enabled Systems: A Personal PerspectiveTesting Machine Learning-enabled Systems: A Personal Perspective
Testing Machine Learning-enabled Systems: A Personal PerspectiveLionel Briand
 
An Empirical Comparison of Model Validation Techniques for Defect Prediction ...
An Empirical Comparison of Model Validation Techniques for Defect Prediction ...An Empirical Comparison of Model Validation Techniques for Defect Prediction ...
An Empirical Comparison of Model Validation Techniques for Defect Prediction ...Chakkrit (Kla) Tantithamthavorn
 
AI-Driven Software Quality Assurance in the Age of DevOps
AI-Driven Software Quality Assurance in the Age of DevOpsAI-Driven Software Quality Assurance in the Age of DevOps
AI-Driven Software Quality Assurance in the Age of DevOpsChakkrit (Kla) Tantithamthavorn
 
System Testing of Timing Requirements based on Use Cases and Timed Automata
System Testing of Timing Requirements based on Use Cases and Timed AutomataSystem Testing of Timing Requirements based on Use Cases and Timed Automata
System Testing of Timing Requirements based on Use Cases and Timed AutomataLionel Briand
 
Systematic Model based Testing with Coverage Analysis
Systematic Model based Testing with Coverage AnalysisSystematic Model based Testing with Coverage Analysis
Systematic Model based Testing with Coverage AnalysisIDES Editor
 
Experiments on Design Pattern Discovery
Experiments on Design Pattern DiscoveryExperiments on Design Pattern Discovery
Experiments on Design Pattern DiscoveryTim Menzies
 
Applications of Machine Learning and Metaheuristic Search to Security Testing
Applications of Machine Learning and Metaheuristic Search to Security TestingApplications of Machine Learning and Metaheuristic Search to Security Testing
Applications of Machine Learning and Metaheuristic Search to Security TestingLionel Briand
 
Using Developer Information as a Prediction Factor
Using Developer Information as a Prediction FactorUsing Developer Information as a Prediction Factor
Using Developer Information as a Prediction FactorTim Menzies
 
6 article azojete vol 9 51 67
6 article azojete vol 9 51 676 article azojete vol 9 51 67
6 article azojete vol 9 51 67Oyeniyi Samuel
 

Tendances (20)

Software Defect Prediction on Unlabeled Datasets
Software Defect Prediction on Unlabeled DatasetsSoftware Defect Prediction on Unlabeled Datasets
Software Defect Prediction on Unlabeled Datasets
 
Metamorphic Security Testing for Web Systems
Metamorphic Security Testing for Web SystemsMetamorphic Security Testing for Web Systems
Metamorphic Security Testing for Web Systems
 
A Tale of Experiments on Bug Prediction
A Tale of Experiments on Bug PredictionA Tale of Experiments on Bug Prediction
A Tale of Experiments on Bug Prediction
 
The adoption of machine learning techniques for software defect prediction: A...
The adoption of machine learning techniques for software defect prediction: A...The adoption of machine learning techniques for software defect prediction: A...
The adoption of machine learning techniques for software defect prediction: A...
 
ESTIMATING HANDLING TIME OF SOFTWARE DEFECTS
ESTIMATING HANDLING TIME OF SOFTWARE DEFECTSESTIMATING HANDLING TIME OF SOFTWARE DEFECTS
ESTIMATING HANDLING TIME OF SOFTWARE DEFECTS
 
Continuous test suite failure prediction
Continuous test suite failure predictionContinuous test suite failure prediction
Continuous test suite failure prediction
 
Scalable Software Testing and Verification of Non-Functional Properties throu...
Scalable Software Testing and Verification of Non-Functional Properties throu...Scalable Software Testing and Verification of Non-Functional Properties throu...
Scalable Software Testing and Verification of Non-Functional Properties throu...
 
Analyzing Changes in Software Systems From ChangeDistiller to FMDiff
Analyzing Changes in Software Systems From ChangeDistiller to FMDiffAnalyzing Changes in Software Systems From ChangeDistiller to FMDiff
Analyzing Changes in Software Systems From ChangeDistiller to FMDiff
 
Can we predict the quality of spectrum-based fault localization?
Can we predict the quality of spectrum-based fault localization?Can we predict the quality of spectrum-based fault localization?
Can we predict the quality of spectrum-based fault localization?
 
June 2010 exam questions and answers
June 2010   exam questions and answersJune 2010   exam questions and answers
June 2010 exam questions and answers
 
A practical guide for using Statistical Tests to assess Randomized Algorithms...
A practical guide for using Statistical Tests to assess Randomized Algorithms...A practical guide for using Statistical Tests to assess Randomized Algorithms...
A practical guide for using Statistical Tests to assess Randomized Algorithms...
 
Testing Machine Learning-enabled Systems: A Personal Perspective
Testing Machine Learning-enabled Systems: A Personal PerspectiveTesting Machine Learning-enabled Systems: A Personal Perspective
Testing Machine Learning-enabled Systems: A Personal Perspective
 
An Empirical Comparison of Model Validation Techniques for Defect Prediction ...
An Empirical Comparison of Model Validation Techniques for Defect Prediction ...An Empirical Comparison of Model Validation Techniques for Defect Prediction ...
An Empirical Comparison of Model Validation Techniques for Defect Prediction ...
 
AI-Driven Software Quality Assurance in the Age of DevOps
AI-Driven Software Quality Assurance in the Age of DevOpsAI-Driven Software Quality Assurance in the Age of DevOps
AI-Driven Software Quality Assurance in the Age of DevOps
 
System Testing of Timing Requirements based on Use Cases and Timed Automata
System Testing of Timing Requirements based on Use Cases and Timed AutomataSystem Testing of Timing Requirements based on Use Cases and Timed Automata
System Testing of Timing Requirements based on Use Cases and Timed Automata
 
Systematic Model based Testing with Coverage Analysis
Systematic Model based Testing with Coverage AnalysisSystematic Model based Testing with Coverage Analysis
Systematic Model based Testing with Coverage Analysis
 
Experiments on Design Pattern Discovery
Experiments on Design Pattern DiscoveryExperiments on Design Pattern Discovery
Experiments on Design Pattern Discovery
 
Applications of Machine Learning and Metaheuristic Search to Security Testing
Applications of Machine Learning and Metaheuristic Search to Security TestingApplications of Machine Learning and Metaheuristic Search to Security Testing
Applications of Machine Learning and Metaheuristic Search to Security Testing
 
Using Developer Information as a Prediction Factor
Using Developer Information as a Prediction FactorUsing Developer Information as a Prediction Factor
Using Developer Information as a Prediction Factor
 
6 article azojete vol 9 51 67
6 article azojete vol 9 51 676 article azojete vol 9 51 67
6 article azojete vol 9 51 67
 

Similaire à Final Exam Solutions Fall02

Istqb question-paper-dump-3
Istqb question-paper-dump-3Istqb question-paper-dump-3
Istqb question-paper-dump-3TestingGeeks
 
Istqb question-paper-dump-5
Istqb question-paper-dump-5Istqb question-paper-dump-5
Istqb question-paper-dump-5TestingGeeks
 
Istqb question-paper-dump-8
Istqb question-paper-dump-8Istqb question-paper-dump-8
Istqb question-paper-dump-8TestingGeeks
 
Istqb exam sample_paper_1
Istqb exam sample_paper_1Istqb exam sample_paper_1
Istqb exam sample_paper_1TestingGeeks
 
Istqb question-paper-dump-1
Istqb question-paper-dump-1Istqb question-paper-dump-1
Istqb question-paper-dump-1TestingGeeks
 
Sample Paper 1233140926359988 2
Sample Paper 1233140926359988 2Sample Paper 1233140926359988 2
Sample Paper 1233140926359988 2mnassef
 
Question ISTQB foundation 2
Question ISTQB  foundation 2Question ISTQB  foundation 2
Question ISTQB foundation 2Jenny Nguyen
 
Đề thi mẫu 2(ISTQB)
Đề thi mẫu 2(ISTQB)Đề thi mẫu 2(ISTQB)
Đề thi mẫu 2(ISTQB)Jenny Nguyen
 
Www.istqb.guru istqb question-paper5
Www.istqb.guru istqb question-paper5Www.istqb.guru istqb question-paper5
Www.istqb.guru istqb question-paper5Tomas Vileikis
 
Deployment of Debug and Trace for features in RISC-V Core
Deployment of Debug and Trace for features in RISC-V CoreDeployment of Debug and Trace for features in RISC-V Core
Deployment of Debug and Trace for features in RISC-V CoreIRJET Journal
 
Software Process Models
 Software Process Models  Software Process Models
Software Process Models MohsinAli773
 
09 cs491 st-t1
09 cs491 st-t109 cs491 st-t1
09 cs491 st-t1NikithaNag
 
Istqb question
Istqb question Istqb question
Istqb question krunal36
 
Csqe sample exam 1 solutions 05.00.04
Csqe sample exam 1   solutions 05.00.04Csqe sample exam 1   solutions 05.00.04
Csqe sample exam 1 solutions 05.00.04binodrit98
 
Istqb question-paper-dump-10
Istqb question-paper-dump-10Istqb question-paper-dump-10
Istqb question-paper-dump-10TestingGeeks
 

Similaire à Final Exam Solutions Fall02 (20)

Istqb question-paper-dump-3
Istqb question-paper-dump-3Istqb question-paper-dump-3
Istqb question-paper-dump-3
 
Istqb question-paper-dump-5
Istqb question-paper-dump-5Istqb question-paper-dump-5
Istqb question-paper-dump-5
 
Istqb question-paper-dump-8
Istqb question-paper-dump-8Istqb question-paper-dump-8
Istqb question-paper-dump-8
 
Istqb exam sample_paper_1
Istqb exam sample_paper_1Istqb exam sample_paper_1
Istqb exam sample_paper_1
 
Istqb question-paper-dump-1
Istqb question-paper-dump-1Istqb question-paper-dump-1
Istqb question-paper-dump-1
 
Sample Paper 1233140926359988 2
Sample Paper 1233140926359988 2Sample Paper 1233140926359988 2
Sample Paper 1233140926359988 2
 
Question ISTQB foundation 2
Question ISTQB  foundation 2Question ISTQB  foundation 2
Question ISTQB foundation 2
 
Đề thi mẫu 2(ISTQB)
Đề thi mẫu 2(ISTQB)Đề thi mẫu 2(ISTQB)
Đề thi mẫu 2(ISTQB)
 
Topic 5 chapter 2
Topic 5 chapter 2Topic 5 chapter 2
Topic 5 chapter 2
 
Cost estamition
Cost estamitionCost estamition
Cost estamition
 
Www.istqb.guru istqb question-paper5
Www.istqb.guru istqb question-paper5Www.istqb.guru istqb question-paper5
Www.istqb.guru istqb question-paper5
 
Istqb Sample Questions
Istqb Sample QuestionsIstqb Sample Questions
Istqb Sample Questions
 
Deployment of Debug and Trace for features in RISC-V Core
Deployment of Debug and Trace for features in RISC-V CoreDeployment of Debug and Trace for features in RISC-V Core
Deployment of Debug and Trace for features in RISC-V Core
 
Software Process Models
 Software Process Models  Software Process Models
Software Process Models
 
Topic 5 chapter 5
Topic 5 chapter 5Topic 5 chapter 5
Topic 5 chapter 5
 
09 cs491 st-t1
09 cs491 st-t109 cs491 st-t1
09 cs491 st-t1
 
Istqb question
Istqb question Istqb question
Istqb question
 
Csqe sample exam 1 solutions 05.00.04
Csqe sample exam 1   solutions 05.00.04Csqe sample exam 1   solutions 05.00.04
Csqe sample exam 1 solutions 05.00.04
 
Higher Homework
Higher HomeworkHigher Homework
Higher Homework
 
Istqb question-paper-dump-10
Istqb question-paper-dump-10Istqb question-paper-dump-10
Istqb question-paper-dump-10
 

Plus de Radu_Negulescu

Intro to Software Engineering - Software Quality Assurance
Intro to Software Engineering - Software Quality AssuranceIntro to Software Engineering - Software Quality Assurance
Intro to Software Engineering - Software Quality AssuranceRadu_Negulescu
 
Intro to Software Engineering - Life Cycle Models
Intro to Software Engineering - Life Cycle ModelsIntro to Software Engineering - Life Cycle Models
Intro to Software Engineering - Life Cycle ModelsRadu_Negulescu
 
Intro to Software Engineering - Software Testing
Intro to Software Engineering - Software TestingIntro to Software Engineering - Software Testing
Intro to Software Engineering - Software TestingRadu_Negulescu
 
Intro to Software Engineering - Software Quality Assurance
Intro to Software Engineering - Software Quality AssuranceIntro to Software Engineering - Software Quality Assurance
Intro to Software Engineering - Software Quality AssuranceRadu_Negulescu
 
Intro to Software Engineering - Software Design
Intro to Software Engineering - Software DesignIntro to Software Engineering - Software Design
Intro to Software Engineering - Software DesignRadu_Negulescu
 
Intro to Software Engineering - Module Design
Intro to Software Engineering - Module DesignIntro to Software Engineering - Module Design
Intro to Software Engineering - Module DesignRadu_Negulescu
 
Intro to Software Engineering - Requirements Analysis
Intro to Software Engineering - Requirements AnalysisIntro to Software Engineering - Requirements Analysis
Intro to Software Engineering - Requirements AnalysisRadu_Negulescu
 
Intro to Software Engineering - Coding Standards
Intro to Software Engineering - Coding StandardsIntro to Software Engineering - Coding Standards
Intro to Software Engineering - Coding StandardsRadu_Negulescu
 
Software Engineering Practice - Software Quality Management
Software Engineering Practice - Software Quality ManagementSoftware Engineering Practice - Software Quality Management
Software Engineering Practice - Software Quality ManagementRadu_Negulescu
 
Software Engineering Practice - Software Metrics and Estimation
Software Engineering Practice - Software Metrics and EstimationSoftware Engineering Practice - Software Metrics and Estimation
Software Engineering Practice - Software Metrics and EstimationRadu_Negulescu
 
Software Engineering Practice - Software Business Basics
Software Engineering Practice - Software Business BasicsSoftware Engineering Practice - Software Business Basics
Software Engineering Practice - Software Business BasicsRadu_Negulescu
 
Software Engineering Practice - Project management
Software Engineering Practice - Project managementSoftware Engineering Practice - Project management
Software Engineering Practice - Project managementRadu_Negulescu
 
Software Engineering Practice - Configuration management
Software Engineering Practice - Configuration managementSoftware Engineering Practice - Configuration management
Software Engineering Practice - Configuration managementRadu_Negulescu
 
Software Engineering Practice - Advanced Development Methodologies
Software Engineering Practice - Advanced Development MethodologiesSoftware Engineering Practice - Advanced Development Methodologies
Software Engineering Practice - Advanced Development MethodologiesRadu_Negulescu
 

Plus de Radu_Negulescu (14)

Intro to Software Engineering - Software Quality Assurance
Intro to Software Engineering - Software Quality AssuranceIntro to Software Engineering - Software Quality Assurance
Intro to Software Engineering - Software Quality Assurance
 
Intro to Software Engineering - Life Cycle Models
Intro to Software Engineering - Life Cycle ModelsIntro to Software Engineering - Life Cycle Models
Intro to Software Engineering - Life Cycle Models
 
Intro to Software Engineering - Software Testing
Intro to Software Engineering - Software TestingIntro to Software Engineering - Software Testing
Intro to Software Engineering - Software Testing
 
Intro to Software Engineering - Software Quality Assurance
Intro to Software Engineering - Software Quality AssuranceIntro to Software Engineering - Software Quality Assurance
Intro to Software Engineering - Software Quality Assurance
 
Intro to Software Engineering - Software Design
Intro to Software Engineering - Software DesignIntro to Software Engineering - Software Design
Intro to Software Engineering - Software Design
 
Intro to Software Engineering - Module Design
Intro to Software Engineering - Module DesignIntro to Software Engineering - Module Design
Intro to Software Engineering - Module Design
 
Intro to Software Engineering - Requirements Analysis
Intro to Software Engineering - Requirements AnalysisIntro to Software Engineering - Requirements Analysis
Intro to Software Engineering - Requirements Analysis
 
Intro to Software Engineering - Coding Standards
Intro to Software Engineering - Coding StandardsIntro to Software Engineering - Coding Standards
Intro to Software Engineering - Coding Standards
 
Software Engineering Practice - Software Quality Management
Software Engineering Practice - Software Quality ManagementSoftware Engineering Practice - Software Quality Management
Software Engineering Practice - Software Quality Management
 
Software Engineering Practice - Software Metrics and Estimation
Software Engineering Practice - Software Metrics and EstimationSoftware Engineering Practice - Software Metrics and Estimation
Software Engineering Practice - Software Metrics and Estimation
 
Software Engineering Practice - Software Business Basics
Software Engineering Practice - Software Business BasicsSoftware Engineering Practice - Software Business Basics
Software Engineering Practice - Software Business Basics
 
Software Engineering Practice - Project management
Software Engineering Practice - Project managementSoftware Engineering Practice - Project management
Software Engineering Practice - Project management
 
Software Engineering Practice - Configuration management
Software Engineering Practice - Configuration managementSoftware Engineering Practice - Configuration management
Software Engineering Practice - Configuration management
 
Software Engineering Practice - Advanced Development Methodologies
Software Engineering Practice - Advanced Development MethodologiesSoftware Engineering Practice - Advanced Development Methodologies
Software Engineering Practice - Advanced Development Methodologies
 

Dernier

9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Commit University
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 

Dernier (20)

9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
20230104 - machine vision
20230104 - machine vision20230104 - machine vision
20230104 - machine vision
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 

Final Exam Solutions Fall02

  • 1. ________________________________ _________________________________ _________________________________ NAME ID SIGNATURE Department of Electrical and Computer Engineering, McGill University ECSE 321 - Introduction to Software Engineering Final Examination December 12, 2002, 2:00pm-5:00pm −−−−ANNOTATED SOLUTIONS−−−− Examination version 1 Prof. Radu Negulescu Associate examiner: INSTRUCTIONS • Write your name, McGill student ID number, and signature in the following places: the cover of the answer booklet, the computer sheet enclosed, and the top of this page. Fill in the corresponding circles on the computer sheet. • Write the examination version number from the box above to the computer sheet enclosed, and fill in the corresponding circle. • This examination consists of two sections: section I consists of 15 multiple-choice questions; section II consists of 4 essay-type questions. Section I is worth 30 marks in total; section II is worth 135 marks in total. The multiple-choice questions are equally weighted; invalid or omitted answers are worth 0 marks. Question 4 of section II offers a choice of two parts, of which you should attempt only one part. • Use pencil only to fill your answers to the multiple-choice questions in the enclosed computer sheet. • Write your answers to the essay-type questions in the separate answer booklet provided. Draw a diagonal line over each scratch sheet in the answer booklet; scratch sheets will not be marked. • This examination booklet has 8 pages, including this page. Keep all pages together. Good luck!
  • 2. Page 2 SECTION I – MULTIPLE-CHOICE QUESTOINS USE PENCIL ONLY TO FILL ANSWERS IN THE COMPUTER SHEET EACH VALID ANSWER GETS 2 MARKS, EACH INVALID OR OMITTED ANSWER GETS 0 MARKS Question 1. Consider the following requirement for a spreadsheet program: “The product shall not offer search and replace options that could have disastruous results.” This requirement is flawed mainly because: (a) It is not feasible. (b) It has implementation bias. (c) It says what the product shall not do instead of what the product shall do. (d) It is ambiguous. (e) No specific reason. Question 2. Consider a system consisting of a client module that passes flags to server modules to indicate which operations should be performed by the server modules. This system has: (a) Unacceptably loose coupling. (b) Unacceptably weak cohesion. (c) Unacceptably tight coupling. (d) Unacceptably strong cohesion. (e) Acceptable but not perfect cohesion and coupling. Question 3. Which of the following statements is true? (a) There is no need to insert breakpoints at every line of code because the “step over” debugger function can achieve the same effect more easily. (b) Good programmers don’t need to use advanced debugger features for increased efficiency if they use assertions to think about the code. (c) Good programmers don’t need to use assertions to think about code if they know how to use powerful debugger features. (d) All of the above. (e) None of the above. Question 4. An advantage of sandwich testing over modified sandwich testing is: (a) Sandwich testing has more coverage. (b) Sandwich testing has fewer test cases. (c) Sandwich testing has fewer test drivers. (d) Sandwich testing has fewer precedence dependencies between test cases. (as shown during the lectures) (e) None of the above. Question 5. An advantage of active design reviews versus Fagan inspections is: (a) Reducing the number of meetings needed. (b) Helping the author to fix the defects found by suggesting how to fix the defects. ((b) is wrong because Parnas’s “active design reviews” are a type of inspection) (c) A better use of reviewer time by eliminating the general meeting. (d) All of the above.
  • 3. Page 3 (e) None of the above. Question 6. The MAIN benefit of performing unit testing before integration or system testing in a large project with high quality requirements is: (a) To save effort in locating defects. (true, but not nearly the most compelling benefit) (b) To save effort in finding failures by easier targeting of test cases to coverage criteria for individual units. (c) To satisfy the customer requirements. (those would be covered by system tests) (d) To disseminate the corporate culture. (e) All of the above. Question 7. Which of the following prototypes is LEAST likely to be needed for clarifying the non-functional requirements of the software controller for a cellular phone: (a) A prototype for reception of signals from the phone branch exchange. (b) A prototype for transmission of signals to the phone branch exchange. (c) A prototype for performance tuning using calibrated stubs. (d) A broad prototype, including transmission, reception, and user interface. (“spike solutions”…) (e) A user interface mock-up with the capability of collecting usage statistics. Question 8. Which of the following statements is true for nearly all software development projects: (a) Unit testing must be completed before integration testing can start. (unit testing overlaps integration) (b) There should be a high-level architecture phase. (not in XP) (c) Every non-functional requirement must be tested. (d) Modified sandwich testing is the best integration testing strategy. (e) All of the above. Question 9. Which of the following statements makes inadequate use of the terms process, project, or product: (a) My web-based project has sub-second response time. (b) The process in our company is quality-oriented. (c) Our product has high reliability. (d) Software projects tend to progress more slowly as they get closer to the release deadline. (e) None of the above. Question 10. Which of the following statements is a reasonable assumption for a typical software project: (a) The probability of failure-free operation is the mean time to failure. (b) The mean time to failure in using a feature is proportional with the number of defects in that feature. (c) The mean time to failure in using a feature is inversely proportional with the number of defects in that feature. (d) All of the above. (e) None of the above.
  • 4. Page 4 Question 11. Which of the following process models is LEAST adequate for implementing the software for an embedded safety belt controller, and what is a reason for the inadequacy: (a) The waterfall model, because the requirements are not well understood. (b) The spiral model, because there are no major risks involved. (c) The V model, because very few tests need to be carried out. (d) The prototyping model, because there is no need for prototypes in this project. (e) The incremental and iterative model, because the controller function cannot be easily split into increments. Question 12. Which of the following process models is MOST adequate for starting a new business in network server firewalls together with your friends, and why: (a) The V model, because it allows more parallelism in development than waterfall. (b) Extreme programming, because it does not have a high-level architecture phase.(close choice, but very bad reason - actually this is a reason why XP is probably not the wisest choice for a project that requires well- thought design of uniform security policies at the system/architecture level) (c) The prototyping model, because requirements are not well understood beforehand. (d) The sharktooth model, because it includes demos of prototypes to the management. (e) The waterfall model, because requirements analysis needs to be performed before writing code. Question 13. Which of the following can NOT be a review criterion for high-level design: (a) Feasibility. (b) Checking whether the static data models are consistent with scenarios of normal usage. (c) Checking whether the static data models are consistent with scenarios of user errors. (d) Absence of implementation bias. (design is always implementation-biased) (e) Security properties. Question 14. Which of the following statements is FALSE: (a) Cyclomatic complexity gives the exact number of test cases needed for complete branch coverage. (b) An upper bound for the minimum number of test cases needed for complete branch coverage can be computed by counting certain keywords in a piece of code. (c) An upper bound for the minimum number of test cases needed for complete statement coverage can be computed by counting certain keywords in a piece of code. (d) If N is the number of nodes and E the number of edges in a flow graph, the cyclomatic complexity of that flow graph is N – E + 2. (e) The cyclomatic complexity of a flow graph is independent of the inclusion or exclusion of nodes for assignment statements in the flow graph.
  • 5. Page 5 Question 15. Consider the following Java method, whose flow graph is shown below: public static int getNumDaysInMonth(int month, int year) throws MonthOutOfBounds, YearOutOfBounds { int numDays; if (year < 1) { throw new YearOutOfBounds(year); } if (month == 1 || month == 3 || month == 5 || month == 7 || month == 10 || month == 12) { numDays = 32; } else if (month == 4 || month == 6 || month == 9 || month == 11) { numDays = 30; } else if (month == 2) { if (isLeapYear(year)) { numDays = 29; } else { numDays = 28; } } else { throw new MonthOutOfBounds(month); } return numDays; } [ y e a r < 1 ] [ m o n t h i n ( 1 , 3 , 5 , 7 , 1 0 , 1 2 ) ] n = 3 2 t h r o w 2 n = 2 9 r e t u r n t h r o w 1 n = 2 8 n = 3 0 [ m o n t h i n ( 4 , 6 , 9 , 1 1 ) ] [ m o n t h = = 2 ] [ l e a p ( y e a r ) ] The minimum number of test cases needed for complete STATEMENT coverage of the method above is: (a) 14 (the right answer for branch coverage) (b) 6 (the right answer for statement coverage) (c) 5 (d) 4 (e) None of the above.
  • 6. Page 6 SECTION II – ESSAY-TYPE QUESTIONS WRITE YOUR ANSWERS IN THE ANSWER BOOKLET Question 1. (requirements, modeling, testing) You are developing the software controller for a vending machine that makes coffee. The machine has a slot for inserting coins, a button for change return, and three buttons for selecting the coffee: Espresso, Cappuccino, and Latte. The machine also has a boiler and a nozzle for delivering the coffee, an output slot for returning the change, and a display for displaying the status of the interaction with the user: amount of money received, steps of making the coffee, error messages, etc. The vending machine operates as follows. The customer inserts coins up to the amount of $1.25, which is the price of a cup of coffee. The machine accepts only quarters and one-dollar coins (loonies). If the amount is exceeded or the coins have the wrong values, the extra coins are immediately returned. For example, if two one- dollar coins are inserted consecutively, the second coin is returned; if six quarters are inserted, the sixth is returned. Immediately following the insertion of each coin, the display confirms the total amount of money received so far. In parallel, the customer selects the coffee desired. If the selection is made after the full amount is inserted, the vending machine makes the coffee and delivers it through the nozzle. If the change return button is pressed before the coffee is made, the money is returned. Throughout the operation cycle, the display is used to acknowledge each user action by indicating the status of the interaction. After the coffee is delivered, the vending machine repeats the operation cycle above. The controller of the vending machine senses and actuates the hardware by invoking methods of a hardware driver object, as follows: • coinInserted(int coin) executes on each insertion of a coin, with parameter coin set to 25 for a quarter and 100 for a loonie; • changeButtonPressed() executes on each push of the change return button; • selectionButtonPressed(String choice) executes on each push of a coffee selection button, with parameter choice set to “Espresso”, “Cappuccino”, or “Latte”, indicating which button has been pressed; • display(String message) outputs the message string on the display; • makeCoffee(String choice) activates the boiler and nozzle to deliver the coffee according to the value of parameter choice; • returnCoin(int coin) returns a quarter if parameter coin is 25 and a loonie if coin is 100. The controller for the vending machine has to be developed according to the DEFENSIVE PROGRAMMING paradigm. (a) Draw a use case diagram for the vending machine controller. Be sure to identify all the main use cases, actors, and their relationships. [5 marks] (b) Draw a state chart describing the behavior of the controller as seen at the interface between the controller and the hardware driver object, i.e., in terms of invocations of the methods above. Use nesting and concurrency to simplify the state chart. [20 marks] (c) Specify a set of test cases that ensures complete transition coverage of the state chart in Part (b).[10 marks] (d) Briefly explain the main reasons for and against using complete transition coverage of a hierarchical state chart as the coverage criterion for testing the vending machine controller (no more than 3 reasons total, one sentence each). [5 marks]
  • 7. Page 7 (a) Coffee selector Money insert Coffee output Make coffee Refund change on request Refund extra change <<extends>> <<extends>> Display watcher (b) cBP() / rC(25), rC(100) cI(25)/rC(25),d(25) cI(100)/rC(100),d(100) SelectCoffee on entry: d(“Cap. selected”) on entry: d(“Lat. selected”) on entry: d(“Esp. selected”) on entry: d(“Please select coffee”) sBP(“Cap.”) sBP(“Esp.”) sBP(“Lat.”) on entry: d(0) cI(100)/d(100) cI(25). /d(125) InsertChange cI(100)/ rC(100), d(50) cI(25)/d(75) / mC(“Cap.”) / mC(“Esp.”) / mC(“Lat.”) on entry: d(“Making Cap.”) on entry: d(“Making Esp.”) on entry: d(“Making Lat.”) MakingCoffee cBP() / d(“Refund expired”) cI(25) / rC(25), d(0) cI(100) / rC(100), d(0) sBP(anyString) / d(“Please wait”) H after 2 seconds on entry: d(“Thanks!”) cI(25)/d(50) cI(25)/d(25) cI(100)/d(125) cBP() cBP()/rC(25) cBP()/ rC(25),rC(25) cBP()/rC(25), rC(25),rC(25) cBP() / rC(100) cI(100)/d(100) cI(100)/ rC(100), d(75) cI(100)/rC(100),d(125) cI(25)/rC(25),d(125) cI(100)/ rC(100), d(100)
  • 8. Page 8 Notes: - The “Thanks” note and “after 2 sec” transition at the end of the cycle are not marked, but the need for them could be inferred from the requirement to display the status of the interaction - specifically, the need to inform the user that the cycle has been completed. - The history pseudostate, marked (H), means that re-entry to the “Making Coffee” superstate is through the last visited substate, or to the “Thanks” state if this si the first entry. Use of the history pseudostate is off the scope of the exam and therefore not marked; the solution can be completed without a history pseudostate, by moving the self-loop from Making Coffee to the substates of Making Coffee and replacing the (H) by a usual initial state. (c) Test insertions: insert the required amount in the three possible ways cI(100); d(100); cI(25); d(125) cI(25); d(25); cI(100); d(125); cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); Test change return on request: go to each state, request return cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); cBP(); rC(100); rC(25); d(0) cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cBP(); rC(100); d(0) cI(25); d(25); cI(25); d(50); cI(25); d(75); cBP(); rC(25); rC(25); rC(25); d(0) cI(25); d(25); cI(25); d(50); cBP(); rC(25); rC(25); d(0) cI(25); d(25); cBP(); rC(25); d(0) Test extra change return: go to 4 states, insert a loonie, get it back; go to last state, insert a quarter, get it back cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); cI(100); rC(100); d(125) cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(100); rC(100); d(100) cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(100); rC(100); d(75) cI(25); d(25); cI(25); d(50); cI(100); rC(100); d(50) cI(25); d(25); cI(25); d(50); cI(25); d(75); cI(25); d(100); cI(25); d(125); cI(25); rC(25); d(125) Test coffee making: sBP(“Cap.”); d(“Cap.”); cI(100); d(100); cI(25); d(125); mC(“Cap”); d(“making Cap.”); d(“Thanks”) sBP(“Esp.”); d(“Esp.”); cI(100); d(100); cI(25); d(125); mC(“Cap”); d(“making Esp.”); d(“Thanks”) sBP(“Lat.”); d(“Lat.”); cI(100); d(100); cI(25); d(125); mC(“Lat”); d(“making Lat.”); d(“Thanks”) Test invalid user actions during coffee making: sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) cPB() d(“Refund expired”) sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) cI(25) rC(25) d(0) sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) cI(100) rC(100) d(0) sBP(“Cap.”) d(“Cap.”) cI(100) d(100) cI(25) d(125) mC(“Cap”) d(“making Cap.”) sBP(anyString) d(“Pls. wait”) (d) Reasons for: - avoids explosion of the number of test cases by avoiding explosion of the number of states and transitions - test cases (targeted to nested/concurrent superstate transitions) map well to independent functional requirements Reasons against: - does not target boundary cases (such as requesting change refund with no credit) which have a rich concentration of defects - does not cover all combinations of concurrent states / interleavings of threads of control, which may trigger desirable events (such as making Cappuccino coffee) as well as undesirable events - does not target internal states and transitions (a black-box rather than structural technique) - such test cases might be difficult to run if they rely on relative timing of the user and multiple threads of control
  • 9. Page 9 Marking: Any two of the above will do. Question 2. (design) You are developing a task management program for a company. The program allocates the company staff to tasks in a way that satisfies the workload constraints of every person in the staff. Each person has constraints on the maximum number of tasks that person can perform at any given time, and this number may vary every week. Tasks may contain sub-tasks, but a sub-task cannot be part of several tasks. Staff is grouped in teams; teams are grouped in departments; departments are grouped in business units. Teams may overlap, i.e., the same person can be a member of several teams. Department and business units may overlap, too. Draw the class diagram for a high-level design model of the task management program. Discuss your main design decisions with respect to the modularity / performance tradeoff (bulleted list form, maximum 5 decisions, maximum 3 lines of explanation per decision). Hint: try to achieve a simpler design by offering a more uniform functionality (as discussed during the design lectures). [30 marks] TaskEntry UI * BasicTask CompositeTask 0..1 GroupEntry * Person Group * BUnitTeam DepartmentConstraint array[week] of taskLimit Allocation array of week AllocationCtrl specifyTaskSet(crtTaskSet) Allocation allocate() * * Company 1 crtTaskSet allocationResult * create specifyTaskSet allocate *1 1 * 1 1 1 * Design decisions: 1. Use the Composite pattern to represent tasks: - Decouples handling of basic tasks from maintaining lists of tasks. - Blends well with the needs of inputting a task set. - Little or no performance cost – traverse just one reference to go through a level of the task tree. 2. Use the Composite pattern to generalize the company hierarchy structure. - It is a more uniform design than a specific department structure – easier to develop, test, extend. - Little or no performance cost – just one reference to go through a level of the groups hierarchy. 3. Allow allocation of hierarchical tasks to hierarchical groups instead of individual persons. - More functionality for no extra complexity.
  • 10. Page 10 4. One control object for each allocation: - Easy to maintain by decoupling consecutive allocations; e.g.threading can be done with minimal impact. - Costs for creation and destruction of objects. Note: Any good solution to this question should abstract the similarities of team, department, business unit, into a superclass (“group”). The decoupling tradeoffs discussed during the first lecture on patterns naturally lead to the composite pattern, which allows any number of levels of the hierarchy. Therefore any good solution offers slightly more functionality with a simpler and more uniform design! A simpler, more uniform design is easier to code, test, maintain, etc. Such is the essence of good software design. Question 3. (analysis, assertions, testing) You are developing a web-based reservation system for a university computer laboratory. The system maintains a daily reservation schedule that consists of 8 one-hour time slots for each workstation in the laboratory. Each semester, each student can reserve up to 100 time slots on individual laboratory workstations. The reservations can be made or retracted at least one day in advance, at any time. To make or retract a reservation, a student accesses the URL of the reservation system, logs in using his or her name and ID, and selects or deselects slots by clicking on the slots in the schedule. On login, the system shows the number of remaining hours to be reserved by the respective student; that number decrements on each selection and increments on each deselection. A student can only deselect slots that are currently reserved by that student, and can only select slots that are not currently reserved by any student. (a) Draw a class diagram for an analysis model of the web-based reservation system. [10 marks] (b) Assuming the design-by-contract paradigm is used at the user interface of the reservation system, specify the pre- and post-conditions for selecting a time slot and for de-selecting a time slot. [10 marks] (c) Assuming the defensive programming paradigm is used at the user interface of the reservation system, specify the pre- and post-conditions for selecting a time slot and for de-selecting a time slot. [10 marks] (d) Assume the system stores references to students who made the reservations, indexed by time slot and workstation number, or null references for free slots; and, the system stores the remaining number of hours for each student. Specify the invariants on the data structure of the reservation system. [10 marks] (e) Derive a comprehensive set of black-box tests for the operations of selecting and deselecting time slots described above. [10 marks] NOTE: Each of the assertions in Question 3 (b), (c), (d) (or (a) if needed) may be specified using mathematical logic, OCL, unambiguous natural language, or combinations thereof.
  • 11. Page 11 (a) Constraint: forall StudentInfo s: s.hoursLeft + #{slot: slot.student = s} = 100 serverObject URLAccessed ReservationCtrl login(name, ID) select(crtSlot) deselect(crtSlot) create *1 ClientUIForm display mouseClicked sendLogin sendCommand 1 login command *1 create * 1 * StudentLog check(name, ID) addStudent deleteStudent check 1* StudentInfo name, ID hoursLeft incrementHours() decrementHours() crtStudent 1* 1 * ReservationLog StudentInfo check(slot) reserve(slot, student) unreserve(slot) check reserve unreserve 1* ReservationSlot day, time workStation StudentInfo check() setStudent (student) crtSlot 1* 1 * 0..1 0..100 Timer day time getCrtTime getCrtTime 1 * if (timer.getCrtTime is at least one day before time and reservationLog.check(slot) indicates a free slot and crtStudent.getHoursLeft > 0) crtSlot.setStudent(crtStudent) crtStudent.decrementHours() // else, do nothing if (timer.getCrtTime is at least one day before time and reservationLog.check(slot) == crtStudent) crtSlot.setStudent(free/null) crtStudent.incrementHours() // else, do nothing (b) – design by contract Select: Pre: crtStudent.hoursLeft > 0 && crtSlot.student == null && time – getCrtTime >= 1 day (&& in-range studentID, reservation day, reservation time slot, workstation number) Post: crtSlot.student' == crtStudent && crtStudent.hoursLeft' = crtStudent.hoursLeft – 1 Deselect: similar Marking: Select: Pre: check hours credit / 1, free slot / 1, current time / 1; Post: make reservation / 1, update hours / 1 Deselect: Pre: check owned slot / 2, current time / 1; Post: undo reservation / 1, update hours / 1 (c) – defensive programming Select: Pre: crtStudent.hoursLeft > 0 && crtSlot.student == null && time – getCrtTime >= 1 day (&& in-range studentID, reservation day, reservation time slot, workstation number)
  • 12. Page 12 Post: if crtSlot.student' == crtStudent && crtStudent.hoursLeft' = crtStudent.hoursLeft – 1 else crtSlot.student' == crtSlot.student && crtStudent.hoursLeft' = crtStudent.hoursLeft in words, if pre is satisfied then the results are correct; if pre is not satisfied then do no updates. OR, equivalently, Pre: none (defensive programming) Post: if (crtStudent.hoursLeft > 0 && crtSlot.student == null && time – getCrtTime >= 1 day) crtSlot.student' == crtStudent && crtStudent.hoursLeft' = crtStudent.hoursLeft – 1 else crtSlot.student' == crtSlot.student && crtStudent.hoursLeft' = crtStudent.hoursLeft Deselect: similar (d) – invariants TOTAL HOURS = 100 / 5 marks forall students s: s.hoursLeft + #slots reserved by s == 100 LIMITS / 3 marks forall students s: s.hoursLeft is in 0..100; and #slots reserved by s is in 0..100 OTHER / 2 marks – at least one from the list forall reservation slots r: r.student is either a the reference of a student object or equal to the null reference unique ID for each student unique workstation ID limits on the # of slots etc. (e) – black-box tests Assumptions: - Since selection/deselection is done by clicking on a posted schedule, only in-range days, timeslots and workstation numbers are tested. - Since selection/deselection follows login, only valid student IDs are tested.
  • 13. Page 13 Input Output Test # Description studentID hrsLeft time-crt time-slot slot status hrsLeft slot status sel.eq.1 Select free slot 1234 38 3/day14 5/day22 free 37 res.1234 sel.eq.2 Select slot owned by other 1234 38 3/day14 5/day22 res.5678 38 res.5678 sel.eq.3 Select same day 1234 38 3/day14 3/day14 free 38 free sel.eq.4 Select <24hrs next day 1234 38 3/day14 2/day15 free 38 free sel.eq.5 Select with no hours left 1234 0 3/day14 5/day22 free 0 free sel.bd.1 Select slot owned by oneself 1234 38 3/day14 5/day22 res.1234 38 res.1234 sel.bd.2 Select first day 1234 100 1/day0 3/day1 free 99 res.1234 sel.bd.3 Select last day 1234 12 3/day5 3/day100 free 11 res.1234 sel.bd.4 Select first slot 1234 12 3/day5 1/day22 free 11 res.1234 sel.bd.5 Select last slot 1234 12 3/day5 8/day22 free 11 res.1234 sel.bd.6 Select exactly 24h before 1234 12 3/day5 3/day6 free 11 res.1234 sel.bd.7 Select with one hours left 1234 1 3/day14 5/day22 free 0 res.1234 sel.bd.8 Select with all hours left 1234 100 3/day14 5/day22 free 99 res.1234 EQUIVALENCE TESTS - SELECT OPERATION BOUNDARY TESTS - SELECT OPERATION Deselect test cases: similar Notes: - It is very important to give specific numbers for inputs and expected outputs, to reproduce the tests and failures. - Other good test cases might be: Select and deselect a slot immediately, and with some other operations in between. Click outside schedule, on the table border, on a border between two slots. Question 4. This question has two parts, of which only one will be marked: either the whole of Part A only, or the whole of Part B only. To obtain credit, indicate clearly in the answer booklet which part you want marked. PART A. (guest lecture) (a) Give two specific examples of dangers entailed when code with inadequate speed optimizations is installed on a different platform. [5 marks] (b) Give two examples of programming guidelines that will help avoid the dangers above. Be sure to actually indicate how following the guidelines will avoid the specific dangers mentioned (one sentence per guideline). [5 marks] (c) Briefly explain three main advantages of choosing software engineering as a career, and two main challenges that arise in practicing software engineering in the industry (one sentence each). [5 marks] PART B. (reliability) Estimate the initial number of faults and the number of defects on release for a software project whose number of faults found per week of quality assurance is as plotted in Figure 1. Assume the software is released on week 15. Assume an exponential reliability growth model as shown by the “interpolated” curve. Show your work by indicating the basis for your calculations. [15 marks]
  • 14. Page 14 QA week # (normalized)1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Faults found (log scale) interpolated 101 102 103 100 Figure 1. Number of faults found during each week of quality assurance in a software project. Part A. (a) Dangers (based on guest lecture - many variations are accepted): (1) Segmentation fault when a routine marks the end of the loop by overwriting protected memory used for input. (2) Unpredictable hardware effects when a routine demarcates input data by overwriting I/O mapped memory used for input. (b) Guidelines (many variations are accepted): (1) Write for people, not for machine: keep code simple, standard style. (2) Document preconditions; include any assumptions regarding pointers to writable memory. This will make compulsory that clients of the routine do not pass pointers to protected or I/O mapped memory for memory areas that need to be writable. (3) Keep right attitude: don’t just be happy when code seems to work, but be sure you know why/how it works; step through new code at least once; this will reduce exposure if the problems above are in someone else’s code (4) Turn on all compiler warnings: writing outside memory may be flagged as such (c) Advantages (any 3 will do): - portable profession: can apply it in a wide range of industries, geographical areas, etc. - wide range of applications: potential of being helpful for diverse types of problems: commercial, medical, etc. - shorter completion cycles: get to see your creations deployed and used - closeness to application: deal with concepts from the problem domain rather than 0/1 abstractions Challenges (any 2 will do): - working with or reporting to non-technical people: frictions due to different expectations and attitudes - dealing with legacy code: hampered by incomplete understanding, bad coding practices of the past - geographical and cultural boundaries: development of a system is distributed around the world
  • 15. Page 15 Part B. Let: N0 = initial number of faults Nrelease = number of faults on release N(t) = number of faults at time t W(t) = faults found during week t From model: W(t) = N0 f(t) = N0 f0 e^(-t f0) => log_10(W(t)) = log_10 (N0 f0) – f0 t / 2.3 => f0 / 2.3 = slope of W(t) line on log scale = 1.5 / 15 = 0.1 => f0 = 0.23 / 5 Also from model: N(t) = N0 (1 – F(t)) = N0 e^(-t * f0) = W(t) / f0 N0 = N(0) = W(0) / f0 =~ 10^2.5 / 0.23 =~ 1375 / 5 Nrelease = N(15) = W(15) / f0 =~ 10 / 0.23 =~ 43 / 5 Notes: - Sanity check: The sum of the number of defects found each week should be N(0) - N(15) = 1332. The actual sum is approximately 2500 – close enough for a ballpark estimate. - In practice, reconcile the estimates: eliminate the garbled points and/or adjust the interpolation until they agree, as in Figure 2 - On the new estimates, f0 = 2.3 * 2/15 = 0.3; N0 = W(0)/f0 = 1000/0.3 = 3333; Nrelease = 10/0.3 = 33. Although N0 changes a lot (2.5x), Nrelease stays close to the original estimate (23%), so the method is pretty good at finding the number of defects on release. QA week # (normalized)1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Faults found (log scale) interpolated 101 102 103 100 Figure 2. Adjusted interpolation.