1. NAME: ID: SIGNATURE:
GOOD LUCK!
Department of Electrical and Computer Engineering, McGill University
ECSE 321 - Introduction to Software Engineering
Midterm Examination
Oct. 31, 2002, 1:05pm-2:25pm
Prof. Radu Negulescu
SAMPLE SOLUTIONS
Question 1. You are developing an automated auction system that uses e-mail to communicate with the bidders.
The bidders log on prior to an auction by sending e-mail to the system. The system communicates the starting
price of an item to all logged-on bidders. The bidders can offer a purchase price equal to or larger than the current
price of the item. The system accepts the highest offer that arrives within a predetermined delay, sets the current
price according to the accepted offer, and conveys the new price to all logged on bidders. If there are no new
offers within the predetermined delay, the system issues two warnings by e-mail to all bidders and, if there are no
further offers, the system declares the item to be sold to the bidder who made the last accepted offer.
Assume the delay for communication by e-mail is much smaller than the pre-determined delay for accepting an
offer; and, registration of items and execution of purchase transactions are outside the scope of the system.
(a) Draw a collaboration diagram for an auction scenario following the description above. [5 marks]
[Marker: Ren Wu]
aB id der
A uction System
1. L og on
3. Initial P rice
5. B id
6. C urrent P rice
8. Issue First
W arning
10. Issue S econd
W arning
12. C lose A uction
2. L og on
4. Initial P rice
7. C urrent P rice
9. Issue First
W arning
11. Issue S econd
W arning
13. C lose A uction
anoth erB id d er

2. Page 2
Notes:
- A collaboration diagram represents a scenario, i.e. an example of usage, including data structure instances
(actor instances and objects) and a behavior instance (one trace).
- Collaboration diagrams and sequence diagrams have equivalent meaning; the layout is different
- Optionally you could include events internal to the system such as closing the logon phase and timer
events that trigger the warnings. Such events would be represented as self-loops at the system object.
Item Marks
Log in 1
Initial Price 1
Bid 1
Current Price 1
Timer Warnings 1
(b) Draw a class diagram for a high-level design model for the automated auction system. Be sure to include
boundary, control, and entity classes, as well as other classes that may be necessary to implement the required
functionality. Indicate the association, aggregation, and generalization relationships between classes, as well as the
main fields and methods. Indicate the multiplicities for each association. [25 marks]
[Marker: Radu Negulescu or Jia Le Huo]
E m ailA daptor
em ail
sen dM ail
receiveM ail
interpretM ail
A uctionC trl
au ction S tate
handleLo go nC m d
in itiateA uction
handleB idC m d
handleT im eout
T im er
d elay
reset(delay)
w akeup()
B idderLo g
ad dB idder
rem oveB id der
notifyA ll
A uctio n
crtP rice
co m pareB id
setC rtB id
getC rtB id
B id derInfo
em ailA d dr
han dleN otif
Item
initialP rice
getPrice
setP rice
crtW inn er
1
*1
*
1
sen dM ail
handleC m d
create
1 *
handleT im eo ut
reset
1 *
com pareB id
setC rtB id
create
1 1
11
M essage
tex t
addr
getT ex t
setT ex t
getA dd r
setA ddr
11
crtB id
w arning
closu re
set,get
receiveM ail
w akeu p
getC rtB id
O n e of: accepting logons
ex pecting in itial bid active bid
n o-b id w arnin g 1 closu re w arning 1
n o-b id w arnin g 2 closu re w arning 2
1
Notes:
- Sufficient information should be included to allow walking through the scenario in part (a)
- Avoid unnecessary coupling. Most but not all students seemed confident with encapsulating functions
together with major groups of data, in true object-oriented style.
- Avoid low cohesion. The vast majority of the students have isolated the timer functionality from the rest
of the system and even seemed to naturally arrive at the Observer pattern for managing the bidder list.

3. Page 3
- Boundary and adaptor classes generally function by having a method invoked automatically on hardware
events; think of applets, servlets, mouse adaptors, etc., etc. Therefore it should not be necessary to poll for
new emails or expired delays.
Marking scheme:
Item Marks
1. Receive mail - Bid - Retrieve bidders - Send
email
4
2. Timeout - Retrieve bidders - Issue warning 3
3. Receive mail - Logon 2
Walkthroughs
4. Set initial price - Retrieve bidders - Send
email
2
5. Some control classes (per use case or merged) 2Classes
6. Some boundary classes (e.g. Email Adaptor,
Timer)
2
7. Observer pattern: managed bidder list +
notification
4
8. Isolate timer subsystem from rest of system 2
Modularity
9. Isolate bidder list management from auction
price management
1
10. Diagram structure (aggregation, multiplicities, sufficient
information in the associations and methods/services to follow the
flow of control)
3
(c) Briefly explain your main design and architectural decisions with respect to the tradeoff of maintainability
versus performance (1/2 page maximum, bulleted list form). [5 marks]
[Marker: Radu Negulescu or Jia Le Huo]
Decisions:
• Decouple application-specific functions (auction, logon) from generic functions (email, timer).
o Great gains in maintainability, reuse, perhaps use of library classes
o Performance is reduced by a constant factor
• Separate control and entity classes
o Decouples dispatching from performing the work
o Performance costs are not too high because all control is done by one object -> less construction
and destruction of objects compared to the Objectory/RUP approach
• Decouple bidder list management from individual bidder info management (observer pattern)
o Great gains in maintainability: the bidder info is very volatile, the bidder list is pretty stable
o Performance is reduced by a constant factor
• Decouple auction management from bidder management
o Great gains in maintainability: these are likely to change separately
o Performance is reduced by a constant factor
• Avoid “BidEvent” and “LogEvent” classes
o Tighter coupling between model and views through type of parameter, but this is not too bad
because they are all custom-made for this application
o Performance is improved significantly by avoiding construction and destruction of many events
• Use a “Message” class
o Performance degrades by construction and destruction of messages
o Avoids coupling most of the entity and control classes to quirks of the email subsystem

4. Page 4
• The notification message is build by AuctionCtrl but updated by Bidder Info with the current Bid
o This minimizes latency and inconsistencies between incoming offers and reported bids
o Decouples BidderInfo to ignore the time, item, and other details known to the AuctionCtrl
o Couples AuctionCrtl and the notify method of BidderLog to the Message class
Notes:
- This question is very design dependent
- Some detail decisions were deferred for lower levels of design, such as:
o Threading and synchronization of threads of the receiveMail and Timer wakeup methods
o Having a separate class for parsing and interpreting mail messages
Marking scheme:
Item Marks
1. Maintainability impact 3
2. Performance impact 2
(d) Use assertions to specify the constraints on the data maintained by the automated auction system and the data
exchanged with the bidders (inputs and outputs). Assertions stated in either natural language, mathematical logic,
or OCL are acceptable. [15 marks]
[Marker: Jia Le Huo]
Constraints on inputs (pre-conditions): none
Constraints on the stored data (invariants):
- The list of bidders contains all bidders who have logged on so far
- In the “accepting logon” state, the list of bidders can only grow
- In all the other states of AuctionCtrl, the list of bidders is the same as during the transition from “accepting
logon” to “expecting first bid”
- crtPrice is the highest price offered by a valid bid so far
- crtPrice can only grow; crtPrice > initialPrice
- crtWinner is the first bidder to bid crtPrice
Constraints on outputs, invariants, and inputs (post-conditions):
- the price and tentative winner in a notification are the ones currently stored in the Auction object
Notes:
- The use of the terms “precondition”, “postcondition” and “invariant” is pretty liberal, because it is difficult
to perfectly separate these types of constraints at the system level; hence it was not required to label the
data constraints precondition, postcondition or invariant
- The system should handle invalid logons and bids, according to the recommendation to use defensive
programming at the interface with the outside world; in the current solution this is done by ignoring them
- The invariants are very design-dependent
- The preconditions and postconditions may also vary with the design assumptions, but to a smaller extent
than the invariants
- Message time stamps might be considered as part of the input and output data
Marking scheme:
Preconditions: none (defensive programming) (3 marks)
Postconditions:
the returned price is the current price (> previous returned price) & (2 marks)
the returned tentative winner is the recorded current winner id/name (2 marks)
Invariants:
Constraints on the bidder list: unchangeable during the auction, number of bidders, etc (2 mark)

5. Page 5
current price ≥ initial price > 0 & (2 marks)
updated price > previous price & (2 marks)
current winner is the first to offer the current price (or other design assumption to resolve the ambiguity)
(2 marks)
Question 2. You are developing VeriLock, a software system for controlling the locks of the doors of a car. The
car has four doors, whose locks can be activated electronically. Each door has controls for locking and unlocking
that door. In addition, all doors can be locked or unlocked simultaneously by a remote control.
(a) Draw a use case diagram for Verilock. [5 marks]
[Marker: Albina Shapiro]
Lock All
Lock
Door
Unlock
Door
Unlock
All
<<include>> Door
Rem ote Cont rol
User
Car User
<<include>>
Notes:
- There is very little room for variation in the choice of actors and use cases according to the principles
discussed
Marking scheme:
Item Marks
Use cases 2
Actors 2
Communication relationships 1

6. Page 6
(b) Draw a statechart diagram that specifies the behavior of VeriLock. Assume that defensive programming will be
used to implement VeriLock. Use nesting and concurrency to simplify the statechart. [10 marks]
[Marker: Albina Shapiro]
Door 1
unlocked
Door 1
locked
manual lock 1
manual unlock 1
manual
unlock 1
manual
lock 1
Door 2
unlocked
Door 2
locked
manual lock 2
manual unlock 2
manual
unlock 2
manual
lock 2
Door 3
unlocked
Door 3
locked
manual lock 3
manual unlock 3
manual
unlock 3
manual
lock 3
Door 4
unlocked
Door 4
locked
manual lock 4
manual unlock 4
manual
unlock 4
manual
lock 4
remote
unlock
remote
lock
Notes:
- This was not an easy question – required some inspiration
- Many students didn’t name the transitions (which are the focus of state diagrams)
- Many students didn’t know how to deal with the defensive programming requirement: all user actions
should have a defined response at all system states
Marking scheme:
Item Marks
States 4
Transitions 2
Concurrency 2
Nesting 2
(c) Draw a class diagram for an analysis model for VeriLock. Include all classes, relationships, attributes, and
methods that are appropriate for an analysis model. [10 marks]
[Marker: Ren Wu]

7. Page 7
L ockC on trol
lockA ll()
unlockA ll()
lock(door)
unlock(door)
getS tate(door)
D oor
lockedState
lock()
unlock()
getS tate()
C ontrolP ad
1
4
B utton
pressed
press()
release()
D oorP ad
lockC m d()
unlockC m d()
R em oteP ad
lockA ll()
unlockA ll()
1 2
1 1
1
5
Notes:
- The analysis model represents the problem statement that includes elements from the problem domain
(deployment environment) and only those elements of the solution domain that will be found in all potential
solutions. Therefore your model should be a subset of the above.
- Your model does not need to include all the details above, but it should represent all the functions mentioned in
the text of the problem. Functional (use case) walkthroughs should be possible at ALL levels of abstraction,
including in the analysis models.
Marking scheme:
Item Marks
Button
Remote
Door
2
Control 1
lock/unlockAll() 1
Classes
lock/unlock() 1
Lock All 2Walkthroughs
Lock Individual 2
Multiplicities 1