Student Answers
Student Answers
By Timothy C. Lethbridge and Robert Laganire McGraw-Hill 2001 International ISBN 0-07-709761-0 US ISBN 0-07-283495-1
PA2
E1.2
E1.3
PA3
E2.2
E2.3
E2.4
E2.5
E2.6 E2.7
E2.8
E2.9
PA4
E2.10 pp. 41-42 Arranging potential classes into inheritance hierarchies (See also E5.21, p. 189) In the following, the hierarchies are shown using indented text to save space. Whether it would be appropriate to actually include all the classes in a given system would depend on the applications requirements. There are many possible variations on these answers. Note: See also E5.21 for additional exercises based on these problems. a)*In this problem we create two separate hierarchies, Vehicle and PartOfVehicle. These could also have something like Machine as a common superclass, although the problem suggested creating separate hierarchies. Vehicle LandVehicle (Added) Car SportsCar Truck Bicycle AirVehicle (Added) Aeroplane AmphibiousVehicle PartOfVehicle Engine JetEngine ElectricMotor Wheel Transmission Vehicle could instead be divided into PoweredVehicle and UnpoweredVehicle; multiple inheritance could be then used for superclasses of the vehicle leaf classes. c)*Schedule (We will learn later that this may not be needed since the whole system stores the schedule) RegularlyScheduledTrip (Added as a superclass representing something that runs at a given time) RegularlyScheduledExpressBus (renamed for clarity) BusRoute ActualTrip (Runs at a given time on a given day; could also be called Run) CharteredTrip (Renamed for clarity) ScheduledTrip (Added to properly complement unscheduledTrip) UnscheduledTrip (Runs on a route, but not at the normal time) BusVehicle (Renamed from bus to distinguish different types of bus) LuxuryBus TourBus e)*Currency (Canadian Dollars and US Dollars are Instances) ExchangeRate (Attributes or associations could be fromCurrency, toCurrency, rate) FinancialInstitution (Added) Bank CreditUnion CreditCardCompany (Visa and MasterCard are instances) FinancialInstrument ReusableFinancialInstrument (Added) CreditCard DebitCard SingleTransactionInstrument (Added) Cheque BankAccount Loan ElectronicDevice (Added) AutomaticTellerMachine (better than BankMachine) BankBranch
THESE ANSWERS SUPPORT THE BOOK OBJECT ORIENTED SOFTWARE ENGINEERING:
PA5
E2.11 p. 47 Describing how polymorphic implementations of certain shape operations would work. a)*translate: In SimplePolygon (as inherited by Rectangle and RegularPolygon), and EllipticalShape (as inherited by Circle), the method translate would move the center. c)*getArea: In Rectangle, the method getArea would return height * width. In RegularPolygon, it would compute the area by dividing the polygon into numPoints individual triangles (see the answer to E2.30 for the detailed algorithm). Once this area is calculated, the total area of the RegularPolygon would be calculated by multiplying the area of each triangle by numPoints. In Circle, the method getArea would return pi * radius2. E2.12 No public answer E2.13 p. 47 Incorporating new classes into an existing class hierarchy that contains considerable polymorphism. a)*IsoscelesTriangle: One might think of making this a subclass of ArbitraryPolygon, however that would be inappropriate since you dont want it to inherit methods such as addPoint and removePoint. A better solution is to make it a subclass of SimplePolygon. As attributes you would have to store the baseLength and height, or else you could store one of the two values for angles and the length of one of the sides, letting the other angle value and side be computed when needed. As methods, you would need changeScale, setBaseLength, setHeight, getArea, getPerimeterLength, getVertices, getBoundingRect, getBaseAngle, getTopAngle, and perhaps setBaseAngle and setTopAngle. E2.14 No public answer E2.15 No public answer E2.16 No public answer E2.17 p. 49 Determining when dynamic binding is needed in a set of polymorphic methods. This exercise has turned out to be particularly useful to ensure students really understand the implications of polymorphism. Before assigning this exercise, it has proved to be necessary to explain the material on pages 48 and 49 particularly carefully, with several examples. Note that the exercise has the assumption, that the compiler knows that no new classes or methods can be added to the hierarchy; it is worth reminding students that this is not generally true in Java (you can add a subclass unless the class is declared final, and you cannot declare a non-leaf class to be final). a)*Invoking getPerimeterLength on a Rectangle variable: No dynamic binding is needed since Rectangle is a leaf class and so the variable could only ever contain an instance of that class. The local method in Rectangle would always be called. c)*Invoking getBoundingRect on a Polygon variable: Dynamic binding would be needed, since either the method in Polygon or the one in Rectangle might have to be executed depending on which class of object is placed in the variable at run time. E2.18 p. 51 Researching products that claim to be object-oriented to determine if they really are. The answer to this question will vary over time, depending on what products are available. E2.19 p. 53 Using documentation to look up library classes and thus better understand a program. This is a purely practical exercise. Its purpose is to encourage students to get in the habit of using documentation. E2.20 E2.21 E2.22 E2.23 E2.24 No public answer No public answer No public answer No public answer No public answer
PA6
No public answer No public answer No public answer No public answer No public answer. No public answer No public answer
PA7
E3.4
E3.5
E3.6
PA8
Generic mechanism, given two cities, that would calculate how many points would be required to fly between them for free for a given user. This would be called when customers are doing queries, and also when a person actually books a free flight to determine how many points to deduct. This would call the first slot below to do detailed calculations. Generic mechanism, given two cities, that would calculate how many points to credit to a particular frequent flier who pays for a ticket. It would be called when the user is making queries, and also when a person actually takes a flight, in order to credit points. This would call the second slot below for detailed calculations. Generic mechanism that runs every month, calling the slot (below) for producing reports, and the hooks (below) for deleting inactive accounts, and perhaps promoting users to different classes. ii. Slots (code that must be provided) A method to evaluate rules regarding how many points are required to fly certain routes for free. A method to evaluate rules regarding how many points are obtained from flying certain routes (might be specific to certain classes of frequent flier, certain times, etc.) A method to produce a formatted printout of a frequent fliers account (each airline may want to make these appear stylistically different from other airlines). Note that instead of creating a slot, this functionality could be left out of the framework entirely. Note that the user interface would have to be provided, but would probably not actually appear as slots in the basic system; the user interface would be a separate subsystem that would simply call the services. iii. Hooks (places where optional add-ons can easily be plugged in) Ability to manage additional types of information about frequent fliers (e.g. work address, email,), beyond the basic minimum information. Different airlines might want to keep different kinds of information for use in marketing etc. Ability to have different classes of users (e.g. prestige users who have accumulated large numbers of points) Mechanism to delete accounts after a certain time period with no activity (this might be activated by the monthly run that prints reports) Ability to add different kinds of points to be used for different purposes (e.g. some airlines, in addition to miles, also keep track of a separate count of miles flown in first class; such points might have different rules, such as expiring after the end of a year). E3.7 p. 70 Evaluating whether or not one should first develop a framework when designing an application. a)* Arguments in favour of developing a full frequent flier framework: Developing the framework improves your overall design. Since you would have to build flexibility into the framework to allow it to be used by others, you would benefit from that flexibility when you have to make changes yourself. As a consequence of the above, you would expect maintenance costs to be reduced; you would also expect to be able to respond faster to market-driven requirements changes. You might be able to sell your framework to others, or to provide frequent-flier services to other smaller airlines. Should two airlines using the same framework decide to work together in an alliance (or to merge) their systems would be more compatible with each other, reducing costs. p.74 Evaluating whether an application should be designed as a client-server system or not. a)*Word processors are not normally designed using a client-server architecture. The following are some of the reasons why not: People typically use word processors on laptop computers or other machines that may not be connected to any network. Although people do share word-processed data, most people work on their own local copy and then share it when they are finished. It might be beneficial to allow a word processor to optionally connect to a server to do such things as load and save data, or to enable two people to edit the same document concurrently. However it would still be necessary to ensure that the user could operate the program while not connected.
E3.8
PA9
E3.9
p.74 Determining the services to be provided by a server. a)*An airline reservation server would be expected to do some of the following activities: Maintain the list of flights along with basic details of each flight (and allow changes) Maintain the prices (and allow changes, special offers etc.) Maintain the bookings (allow bookings to be made, changed and deleted) Allow people to query all of the above
E3.10 p. 79 Evaluating the balance of work on the client and server side of a system. a)*For an airline reservation system: i. Server work: See exercise E3.9. ii. Client work: Enter queries about available flights and display the results. Enter bookings Display and print itineraries iii. Information transmitted from server to client: Results of queries (relatively simple text) iv: Information transmitted from client to server: Simple commands and their arguments. v: How the clients work could be minimized or maximized: The client might be interacting with several different reservation systems, producing overall itineraries that would combine the results from several servers. A server could be developed to provide this function interacting with other servers and managing itineraries. The client could, on the other hand, be given a lot of intelligence to work out itineraries and good deals. It could find the best prices, and even run a bidding mechanism that would try to get airline servers to give better deals. The client could simply be a web browser with no intelligence at all about the frequent flier domain. vi: Network effects of changing the clients workload: Putting more intelligence into the server (such as having the server interact with other servers) would have only a moderate effect on the quantity of information transmitted in the network as a whole. Adding extra intelligence to the client might result in large numbers of queries being transmitted, and large numbers of replies returned. The client would need to perform these queries in order to marshal the information it needs to make decisions. Having the client become nothing more than a web browser, would probably increase network traffic from the server to the client, since now the server would have to transmit images and all the other information that will make the UI of the client look nice. E3.11 p. 80 Writing protocols for a client-server system. There are clearly many possible protocols for these systems; the level of complexity could become substantial. the following shows some basic sets of messages that could be exchanged. a)*Airline reservation system. Note that a real system can be extremely complex; the following represents a simplified view of the kinds of messages that such a system would need to exchange. Messages to server Possible replies to client addRegularFlight number planeType effectiveDate confirmFlightAdded number flightNumberAlreadyExists addFlightLeg flightNumber origin leaveTime destination arriveTime confirmLegAdded flightTimeConflictsWithAnotherLeg deleteRegularFlight number effectiveDate confirmDeletion flightNumberDoesNotExist
2002 TIMOTHY C. LETHBRIDGE AND ROBERT LAGANIRE
PA10
addFareClass fareCode confirmFareClass fareClassAlreadyPresent setFare origin destination classCode startDate endDate confirmFare addBooking name date flight originCity destinationCity fareClass confirmBooking confirmationNumber seat bookingCannotBeMade reason deleteBooking confirmationNumber confirmBookingDeletion bookingNotCancelled reason confirmationNumberInvalid queryFlightAvailability date origin destination fareClass earliestDepTime latestArrTime availableFlight date flightNumber fareClass noMatchingAvailableFlight queryBookings name date confirmBooking confirmationNumber seat queryBookingsByNumber confirmationNumber bookingInfo flightNumber date name origin destination fareClass seat queryPassengers flightNumber date bookingInfo flightNumber date name origin destination fareClass seat
PA11
E4.2
E4.3
E4.4
E4.5
E4.6
E4.7
PA12
c)*Constraint on availability and throughput - The system will accept connections 24 hours a day, every day, with a maximum downtime of 5 minutes a month, which can occur only between 12:30 a.m. and 1:30 a.m. North American Eastern Time. - When available, the system will at all times be able to manage 200 simultaneous connections, and process 2000 transactions per minute. E4.8 E4.9 No public answer. p. 119 Writing non-functional requirements. These build on the answers to E4.3 - E4.5 above. a)*Police information system When the user is connected to the over a local area network, the system shall respond with complete responses to all inputs within 0.5s at peak system load. When the user is connected over a wireless connection at 9600bps, the system shall respond with complete responses to all inputs within 3s at peak system load. The system shall be capable of handling 50 simultaneously connected users, and 300 user interactions (events originating from users) per minute. The system shall not consume more than 200MB of RAM while running at peak capacity. The system shall not consume more than 56Kbps of bandwidth per connected user (averaged over any 1s time period) The system shall achieve a reliability level of no more than 1 failure per 10 user hours, with none of those failures rendering the system totally inoperable. The system shall be available 99.9% of the time with no period of down time exceeding 2 minutes. The system shall be designed so that large numbers of additional functions can be added with little reprogramming. The system shall be designed so that it could be adapted to the needs of other police departments with minimal reprogramming. The server shall be able to run on a Windows 2000 (or higher) equipped system, with a 1.4 GHz or faster Intel processor, 300MB or more of RAM, and 15GB or more of disk space. The client software shall be able to run on EMP-4500 police car terminals, as well as on EMP-4500 emulators running on desktop computers.
E4.10 p. 122 Practising interview techniques. This is a purely practical exercise. E4.11 p. 124 Practising brainstorming techniques. This is a purely practical exercise. E4.12 No public answer E4.13 No public answer E4.14 No public answer E4.15 pp. 129-130 Describing the type of requirements document needed. a)*Software controlling a manned spacecraft sent to Mars There would need to be a considerable amount of detailed technical requirements documentation. Technical terminology could be used since all readers would be expected to have a technical background. There would probably initially be a very high-level description of the missions overall objectives used to obtain funding for the mission. Then there would be a requirements document for the high-level system requirements of the combined hardware-software system. Next, the system would be allocated into hardware and software subsystems, which in turn would each be divided into several subsystems. At each level there would probably be general and detailed requirements documents. The rationale for this level of detail is that a spacecraft is novel, is technically complex, will involve many different people with different types of expertise to develop, is difficult or impossible to change once launched, and is expensive (with high failure cost and hence a high level of required reliability).
THESE ANSWERS SUPPORT THE BOOK OBJECT ORIENTED SOFTWARE ENGINEERING:
PA13
E4.16 pp. 135-136 Finding problems in requirements statements. a)*Simple interest calculation program The requirements are not separated into individual points This is a handy utility is too informal It is not clear whether the fields are updated upon every keystroke, or whether the user has to hit enter or click on some button to cause an update of the fields. It is not clear whether the monthly payments are at the start or end of each month (this effects the computation). (The computations themselves are well-known by accountants, so it is legitimate to exclude them) There is no information about the platform on which the program runs, Maximum and minimum dollar amounts and interest rates that can be handled should be specified. Precision of calculations should be specified. What happens if the user enters invalid keystrokes? It would be desirable to describe the user interface in a little more detail. E4.17 p. 136 Rewriting requirements to remove defects. a)*Simple interest calculation program Functional Requirements - When the system starts, a window appears, whose content and function is describe below. - The window has the title Simple Interest Calculation, as well as standard close and minimize icons in the title bar. - The window has labels Principal:, Annual interest rate:, Interest paid at the end of each month:. The right edges of these are vertically aligned, and each is followed on the right by an input field - The principal and interest fields are capable of accepting 10 characters of input, the interest rate field is capable of containing 8 characters. - The user may enter numeric values in each field; as each key is typed (including the delete key), the other fields are updated instantly. An empty field is taken as having the value zero. - Editing the interest rate causes a change to the monthly payment. - Editing the monthly payment causes a change to the interest rate - Editing the principal causes a change to the monthly payment - The user may use the mouse to move the insertion point or select characters in any field, as in standard Windows applications. - The system can handle dollar amounts from -999999.99 to 9999999.99, and interest rates from 999.99% to 999.99%. The percent symbol is automatically added if the user does not specify it. - All calculations are rounded to the nearest cent. Two decimal places are always shown in all three places. - Any edit to a field that would result in an invalid input, or a computed result that could not be displayed in the other fields, will not be accepted the system will beep and display an error message at the bottom of the window describing the error. Error messages include: The largest value accepted for <field> is xxx The smallest value accepted for <field> is xxx Input must be numeric Input is only accepted to two decimal points A <field> input value of xxx would result in an invalid value for <field> Non-functional Requirements - The program will run on all Microsoft Windows operating systems starting with Windows 95 and Windows NT 4.0 (on all CPUs of at least 33Mhz). - Response time will appear instantaneous to users. E4.18 No public answer E4.19 No public answer E4.20 No public answer
2002 TIMOTHY C. LETHBRIDGE AND ROBERT LAGANIRE
PA14
Wheel
E5.3
p. 160 Explaining the consequences of associations in terms of creation and destruction of instances This exercise has several parts that are strongly analogous to each other, and which turn out to be candidates for association classes, which are described on page 161. a)*A Vehicle could exist, and then a Wheel could be created and associated with it; conversely, the wheels could exist first. Similarly, the order in which these associated objects are destroyed does not matter. c)*Under normal circumstances in the real world, a country exists over a longer period of time than any of its heads of state. However, if we imagine an information system storing biographical information, then a person might be created in the system who later on is recorded as the head of state of a country. So there are no necessary constraints on the order of creation or destruction of these instances. e)*This is similar to parts b and d. The Registration would be created after the Member and the Activity, and would have to be destroyed no later than these associated instances. (In some circumstances, the Member and the Registration could be created together). p. 160 Reading associations in both directions. The exact phrasing of answers to this question will, of course, vary considerably. This exercise has proven particularly valuable at getting students to check their work and detect errors in their class diagrams. Creating these answers even helped us make improvements to our answers to E5.2. Different answers to E5.2 would result in different answers to this question. a)* A Vehicle can have no Wheels, or an unspecified number of Wheels. A Wheel always belongs to exactly one Vehicle. c)* A Country has either zero or one known HeadOfState. A HeadOfState can head any number of Countrys e)* A Member can register in any number of activities (can have any number of Registrations) Each Registration involves registering exactly one Member in exactly one Activity An Activity can have an arbitrary number of Registrations p. 162 Adding association classes. The question doesnt require a list of attributes, but we show attributes below to help explain the purpose of the association class. a)*A reasonable association class might be called PlayingRecord or something similar. The attributes needed would depend on the type of sport, but might include positionPlayed, goalsScored, penalties and timeOnField
Player
* *
E5.4
E5.5
SportGame
PlayingRecord
positionPlayed goalsScored penalties timeOnField
PA15
No public answer No public answer No public answer No public answer No public answer No public answer
E5.12 p. 175-176 Writing OCL constraints. a)*Referring to Figure 5.11, p. 164 context RecordingCategory inv: subcategory->forAll(r | self <> r) E5.13 p. 178 Designing how operations would be performed a)*In this example it is ambiguous whether getSiblings should include half siblings or just full siblings; we assume the former. getSiblings (a method of Person) would be performed as follows: 1 Obtain the parents (a Union), by following the association 2. For the femalePartner of the Union: 2.1 For each of her Unions 2.1.1 Put the children of the Union in the result set (excluding duplicates and the self object) 3. Repeat step 2 for the malePartner 4. Return the result set c)*Step siblings are children of a persons step-parent which are not half-siblings. To solve this problem we will first define a method of Person called getStepParents, as follows: 1. Obtain the parents (a Union we will call mainUnion). 2. For the femalePartner of the mainUnion: 2.1 For each of her Unions other than the mainUnion 2.1.1 Put the malePartner in the result set 3. Repeat step 2 inverting femalePartner and malePartner 4. Return the result set Now we can define the getStepSiblings method of Person: 1. For each stepParent obtained by calling getStepParents 1.1 Add each of the children of the stepParent to the result set 2. Call getSiblings to obtain the set of siblings 3. Subtract the siblings and self from the result set 4. Return the result set E5.14 p. 178 Writing OCL constraints for the genealogical example. a)*context Person inv: dateOfDeath = or dateOfBirth = or dateOfBirth <= dateOfDeath E5.15 No public answer E5.16 No public answer E5.17 No public answer
PA16
E5.18 p. 184 Making a preliminary list of classes by listing noun phrases in requirements. In the following, we simply list a reasonable initial set of classes based on a first scan of the nouns in the problem descriptions. Other lists are possible. Not all the nouns shown will end up in the final answers, shown in the answer to E5.20. Classes where there is some initial doubt are marked ??. a)*Bank account management system (p. 448) Service ?? BankAccount Branch Client MortgageAccount, ChequingAccount, CreditCardAccount Property ?? CreditCard JointAccount ?? Privilege ?? Division, SubDivision ?? Manager, Employee ?? Nouns not on the list because they will probably not be classes in the system: System (because it is not part of the domain) OOBank (an instance) address, branch number (attributes) account number, balance, credit limit, overdraft limit (attributes) interest rate, monthly fee (attributes) husband, wife (information in an example only) cheque, insurance (possibly beyond the scope, may become classes later) Planning, Investments, Consumer, Consumer Division (instances) personal banker (association) E5.19 No public answer E5.20 p. 189 Adding generalizations or interfaces to a class diagram. a)*Bank account management system: See 5.21e for a related problem.
worksFor
Person
subdivision * name manager 0..1 *
OrganizationalUnit 0..1
0..1
AccountType
interestRate monthlyFee checksAllowed insuranceAvailable
Employee
personalBanker
Customer
* 1..2
accountHolder *
Branch
address number
* *
Account
number balance creditOrOverdraftLimit
CreditCard
name 1..*
ChequingAccount
MortgageAccount
collateralProperty
CreditCardAccount
expiryDate
The distinction between AccountType and Account is important (so that each Account does not need to store its own interest rate). There is a good chance, however, that students will not make this distinction in their initial answers. The following are some variations:
THESE ANSWERS SUPPORT THE BOOK OBJECT ORIENTED SOFTWARE ENGINEERING:
PA17
A customer is not always a person, so the generalization here may need to be changed so the top class is LegalEntity, which has Customer as a subclass (or the generalization can be removed entirely) There can be separate Department and Division classes, although the solution shown, using OrganizationUnit is more flexible). It is important, however, not to add a separate class for each division, as that would be very inflexible. Each individual credit card may have its own number. CollateralProperty and Address may be classes instead of simple attributes You might add a separate Privilege class associated to AccountType, instead of the attributes checksAllowed and InsuranceAvalable. E5.21 p. 189 Additional exercises in drawing class diagrams, based on E2.10 (p. 41). Since each of these lacks detail regarding the requirements, we have had to suggest the attributes and associations that should be present. Note that each of these represents only part of a final system many details (e.g. additional classes) have been omitted. a)*Vehicles: We assume data is being maintained for hobbyists interested in data about a wide variety of vehicles and their parts. In this answer, we decided to follow the pattern found in Figure 5.12 creating a VehicleCategory class instead of modelling each type of vehicle as its own class. Students who created the class hierarchy in E2.10 might simply transcribe it here; however, it is a good learning exercise to show that although the hierarchy of E2.10 might have been good for preliminary domain modelling, the answer below is much more flexible (it allows new vehicle types to be added without extra programming). Note also that question E6.2 is related to this.
VehicleCategory description powerSource
* * subcatgegory * isOfCategory * hasParts
c)*Bus scheduling: We assume a system for a bus company that runs regular routes as well as charters. This has much in common with the Airline system (see the answer to E5.26). Note the following points: The subclasses of BusVehicle have been merged, and the attribute category is used to determine whether the bus is a luxury one or not. Although it would seem that TripOnRoute would have no distinguishing features, and thus not need to exist as a separate class, in fact it could contain the abstract operation getRoute, which would be implemented differently in its two subclasses. Information about bus stops not included in this model, but would be rather important.
PA18
TripOnRoute
ScheduledTrip
*
UnscheduledTrip
*
RegularlyScheduledTrip depTime
e)*Financial institution: See 5.20a for a similar problem (that also includes the notion of customers which are omitted here). Note the following points about this answer: We have decided to make BankAccount a kind of FinancialInstrument; this is a bit different from what we did in the answer to E2.10e, but has the advantage that it allows the denomination association to inherit nicely. It is well known that debit cards have PINs. Some have argued that credit cards dont. In fact they do but the PINs are not used in some jurisdictions.
FinancialInstitution name Branch CreditCardCompany Bank
hasBranches *
name address
Currency
issuer
FinancialInstrument
denomination *
code exchangeRate
Cheque
drawnAgainst amount date * sequenceNumber 1..*
DebitCard
connectedAccounts
Loan monthlyPayment
E5.22 p. 192 Determining responsibilities for each class. It is important that these be simple phrases. Suitable classes for the responsibilities are given in parentheses. In some cases the word singleton is used to indicate that the responsibility could be added to a singleton class not shown in the answer to E5.20. There are sometimes several choices for suitable classes; all suitable choices are listed, with the suggested one in italics. The plus symbol indicates that there should be several polymorphic implementations in subclasses a)*Bank account management system. Adding a new customer (singleton, static Customer) Changing details of a customer (Customer) Opening an account (static Account +) Crediting an amount to an account (Account) Debiting an amount from an account (Account) Changing the credit or overdraft limit on an account (Account)
THESE ANSWERS SUPPORT THE BOOK OBJECT ORIENTED SOFTWARE ENGINEERING:
PA19
Issuing a new credit card (CreditCardAccount) Adding a new employee (OrganizationalUnit) Changing details of an employee (Employee) Assigning a personal banker to a customer (Customer, Employee) Adding a new branch (singleton, static Branch) Changing the address of a branch (Branch) Changing an employees reporting relationship (Employee) Changing the divisional structure in the organization (OrganizationalUnit) Adding a new account type (singleton, static AccountType) Changing details of an account type (AccountType)
E5.23 No public answer E5.24 p. 194 Adding operations to a class diagram. These could be listed inside class boxes; however, we have just shown them as simple lists following each class. a)*Bank account management system Account Account(overdraftLimit, accountType) credit(amount) debit(amount) changeOverdraftLimit(amount) ChequingAccount ChequingAccount(overdraftLimit, accountType) MortgageAccount MortgageAccount(initialBal, accountType, propertyDescription) CreditCardAccount CreditCardAccount(accountType) addCard(name) AccountType changeInterestRate(newRate) changeMonthlyFee(newFee) changeChequingPrivilege(checksAllowed) changeInuranceDetails(insuranceDescription) Person (no operations at this level of analysis) Employee changeName(name) changeOrganizationalUnit(newOrganizationalUnit) Customer assignPersonalBanker(employee) Branch changeAddress(newAddress, newPhoneNumber) OrganizationalUnit addEmployee(name) changepParentUnit(newParentUnit) E5.25 No public answer E5.26 No public answer E5.27 No public answer
PA20
No public answer No public answer No public answer p. 221-222 Determining the pattern(s) that would apply in specific design circumstances. a)*Adapter (in your inheritance hierarchy create an adapter class that whose methods delegate to those in the class you want to reuse) Note, parts a also uses delegation, but this is not the dominant pattern here.
PA21
E7.2
E7.3
Postconditions: The system has stored the bill physically, and has a record of the transaction. The actor has a receipt for the transaction.
PA22
E7.4
p. 238 Drawing use case diagrams a)*Library system (based on example 4.9, page 126) We give two answers for this: The first does not use generalization, which had not yet been discussed in the text in the context of use case diagrams. This diagram is excessively complex so would not be worth drawing in a real software engineering project.
Search for items by title
Borrower Add a new item Delete an item Change an item's information Librarian
Search for items by author Search for items by subject Place a book on hold
Check out an item Check in an item Renew an item Record fine payment Add a borrower
Accounting System
The second version of the answer uses generalization, showing how the diagram can be simplified (fewer lines)
Place a book on hold Check personal information Borrower Check out an item Check in an item Renew an item Add a borrower Search for items by title
Search for items by author Accounting System Update a borrower's information Record fine payment
Checkout Clerk
PA23
E7.5
p. 240-241 Writing use cases for the car park system. a)* Use case: Exit car park by paying using a debit card. Goals: To leave the parking lot after having paid the amount due using a debit card Preconditions: In addition to exit car park preconditions: The driver must have available his or her debit card and know the PIN. The driver must have sufficient funds in his or her bank account. Related use cases: Specialization of: Exit car park Steps:
Actor actions 1. Drive to exit barrier, triggering a sensor. 3. Insert ticket. 5.1 Insert debit card. 5.2. Specify account. 5.3. Specify PIN. System responses 2a. Detect presence of a car. 2b. Prompt driver to insert his or her card. 4. Display amount due. 6.1 Prompt for account (chequing/savings). 6.2. Prompt for PIN. 6.3a. Debit account. 6.3b. Eject debit card. 6.3c. Prompt driver to take debit card. 6.4. Raise barrier. 8. Lower barrier.
Postconditions: In addition to Exit car park postconditions: The drivers bank account has been debited. E7.6 E7.7 No public answer p. 242 Listing use cases and prioritizing them. a)*A telephone answering machine. Record outgoing message Record incoming message Listen to incoming messages Skip back to previous message Erase a message Skip to next message Record a conversation p. 257 Creating error messages for a user interface. a)*There are unlikely to be any error messages on this screen! p. 257 Determining whether response time is adequate at a web site. The answer to this exercise depends on the design of the web site chosen (and that web sites response time may change from time to time).
E7.8 E7.9
E7.10 p. 257 Preparing a paper prototype. This a practical exercise with no specific right answer. E7.11 No public answer E7.12 p. 258 Performing heuristic evaluations of user interfaces. The answers to this exercise depend on the programs chosen, the versions of those programs, and the parts of the programs evaluated. E7.13 p. 258 Performing a heuristic evaluations of a web site. The answers will depend on the web site chosen.
2002 TIMOTHY C. LETHBRIDGE AND ROBERT LAGANIRE
PA24
E7.14 p. 258 Having multiple people conduct separate heuristic evaluations. This is another subjective exercise. E7.15 p. 259 Performing heuristic evaluation of a GANA prototype and updating the UI. This is another subjective exercise. E7.16 p. 260 Performing an evaluation of a UI by observing users. This is another subjective exercise.
PA25
:Loan
E8.2 E8.3
No public answer p. 275 Drawing more collaboration diagrams These correspond to the answers to E8.1 a)*Library example
GUI 1:foundBook := search(title) :Library
2:borrow
foundBook: CopyOfBook
E8.4 E8.5
No public answer p. 279 Determining the state the system would be in after a sequence of events. a)*It would be in state Cancelled. Rationale: Initial = Planned; openRegistration -> OpenNotEnoughStudents (classSize=0); requestToRegister -> OpenNotEnoughStudents (classSize=1); requestToRegister -> OpenNotEnoughStudents (classSize=2); cancel->Cancelled No public answer No public answer No public answer No public answer No public answer No public answer No public answer No public answer
PA26
ProposeSelection
AcceptingMoney
pressReturnMoney /returnMoney
[enoughMoney]pressSelection /returnChangeIfNecessary
MusicPlaying
do: play chosen selection
E8.15 No public answer P8.2 p. 291 Drawing state diagrams of OCSF and SimpleChat a)*ConnectionToClient in the OCSF Framework: Note that events such as setHost have not been modelled here.
Running
/clientConnected message/ receiveMessageFromClient
Initializing AcceptingMessages
IOException exception/ clientException sendToClient/ send
Terminating
close/ clientDisconnected
ReadyToTransmit
PA27
E9.8 E9.9
E9.14 p. 339 Designing the architecture of systems. a)*A corporate payroll system. To be provided.
PA28
PA29
- Boundary cases 01, 12 2 Invalid: 1 to 9 (assume we explicitly require two digits) - Boundary cases 1, 9 3 Invalid: 00 and 0 4 Invalid: 13 to 99 - Boundary cases 13, 99 5 Invalid: Empty string 6 Invalid: String with non-numeric characters Day 1 Valid: 01 to 28 - Boundary cases 01 and 28 2 Valid: 29 in February of a leap year, or in any other month any year. 3 Invalid: 29 in Frebruary of a year other than a leap year. 4 Invalid 30 (in February) 5 Valid: 30 (in some month other than February) 6 Invalid: 31 (in a 30-day month or in February) 7 Valid: 31 (in a 31-day month) 8 Invalid: 32-99 - Boundary cases 32, 99 9 Invalid: 00 and 0 10 Invalid: 1 to 9 (2 characters required) - Boundary cases 1, 9 11 Invalid: Empty string 12 Invalid: String with non-numeric characters Street Address: Valid: Character strings of length 2-40 (assumed limits) containing upper and lower case characters, numbers, comma, period, hyphen, single spaces, accents and diacriticals Boundary case: Strings of length 2 and 40 Invalid: Character strings containing non-printable characters Invalid: Character strings with more than one embedded space Invalid: Strings of length 0-1 City, Country and Postal code Same as street address, except that country and postal code can have 0 characters Home Telephone Number Valid: Empty string Valid: String of characters including digits, +, ( ), -, x and space Invalid: Other strings of characters E10.4 p. 355 Determining boundary values. See the lines marked boundary cases in the answer to E10.3 E10.5 No public answer. E10.6 p. 358-359 Tables of conditions for testing purposes. a)*Message forwarding To be provided. E10.7 No public answer E10.8 pp. 365-366 Classifying and testing for numerical defects. a)*Assuming a floating point value will be exactly equal to 3.0, when it might be slightly different from this.
2002 TIMOTHY C. LETHBRIDGE AND ROBERT LAGANIRE
PA30
E10.9 No public answer E10.10 No public answer E10.11 p. 372 Designing stress and unusual-situation tests. a)*A new web browser Loading a truly massive web page full of complexity. Loading a web page containing a large amount of JavaScript. Loading a web page containing several large Java applets. Loading a web page full of html errors Loading a web page with obsolete html constructs Loading a web page with the latest complex html and cascading style sheet constructs Loading a web page that contains an extremely large number of levels of nested html tags. Loading a web page containing tables with an extremely large number of columns and rows. Loading a web page demanding a lot of width of the resulting output Loading a very large web page that contains a large number of embedded objects. Testing the browser on an extremely slow connection. Loading a very large number of web pages at once in multiple windows. Running on a variety of different versions of the target operating system. Running on a machine with too little memory Running on a machine with too little disk space for caching purposes. Loading random pages over and over again for a long time (using a driver) Running on a very small screen Dealing with repeated failures of connections E10.12 p. 376 Writing test cases. a)*Message forwarding To be provided. E10.13 No public answer. E10.14 No public answer. E10.15 p. 387 Conducting code inspections. This is a purely practical exercise
PA31