Midterm Exam Solutions Fall02


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Midterm Exam Solutions Fall02

  1. 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. 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. 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. 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. 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. 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. 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