Solution manual PDF

Title Solution manual
Author Taimoor Ahmed
Course Advanced Topics in Distributed Computing
Institution COMSATS University Islamabad
Pages 31
File Size 425.2 KB
File Type PDF
Total Downloads 21
Total Views 204

Summary

solution manual of software engineering using uml diagram and patterns...


Description

Object Oriented Software Engineering: Practical software development using UML and Java By Timothy C. Lethbridge and Robert Laga nière McGraw-Hill 2001 International ISBN 0-07-709761-0 US ISBN 0-07-283495-1

Public Answers to Selected Exercises – Version 1.9 (August, 2002) © 2002 Timothy C. Lethbridge a nd Robert Laganière The following contains answers to a subset of the exercises in the book, along with explanations of some aspects of the a nswer s. In some cases the provided answers ar e more detailed those that would be expected from students. Also note that some questions are subjective, so r eader s may have responses different from those written her e. The a nswer s provided here ar e publicly a vailable on the website so a s to enable students to pra ctise. Genera lly spea king, the a nswer s given her e are parts a of multi-part questions; in exercises with many pa r ts, a nswer s may a lso be given to par ts c and e. The full set of answers is only a vaila ble to instructors a s a separa te password-protected document. We update these answers fr om time to time, adding improved explanations, alterna tive a nswer s, and extra exer cises. You can contact us a t [email protected] .ca with suggestions. Items which we plan to complete or a ugment a t a later date ar e mar ked in green. Please look at our web site (w ww.lloseng.com) for other information about this book, including: • A knowledge ba se containing many of the basic facts fr om the book • Videos of Tim Lethbridge presenting lec tures based on the book. • The slides that have been prepa red for professors who teach using the book

PUBLIC ANSWERS TO EXERCISES

PA2

Chapter 1. Software and Software Engineering E1.1

p. 5 Classifying software. a )*Custom; rea l-time. c)*Gener ic; real-time (but soft real-time).

E1.2

p. 10 Stakeholder reactions to situations. a )*• The user may be disappointed, since he or she might be looking forwa r d to no longer having to do this par ticular type of work. On the other ha nd, he or she may be relieved a bout not being put out of wor k. • The customer ma y be disappointed at not being a ble to save money; he or she ma y also be surprised, since many people believe that softwar e systems are easy to develop; they underestimate the complexity of ta sks that a re to be automated. The customer might consult some other softwar e engineer to obtain a second opinion. • The developers will proba bly move on to other wor k. • The development managers may be disappointed at not having the opportunity to do further work on the pr oject.

E1.3

p. 12 Prioritizing quality attributes a )*Reliability will be pa ra mount for the spac ecra ft softwar e. It would be sad if the spacecr aft did not make it into orbit after all that time, a lthough no lives would be lost. Efficiency might be important since processors fr om 20 year s ear lier ar e far slower tha n today’s devices. Usability will likely not be a n issue since the softwa re will r un autonomously and r eport a ny feedback to experts; fur thermore the softwar e cannot be intera ctive since it takes considera ble time to send signals to and fr om Pluto at the speed of light. Maintainability is a lso likely to be a minimal concer n since this softwar e is likely to only be used once. However, ther e remains the possibility that the softwar e could be used on other systems, or will need to be cha nged as last-minute bugs are fixed. c)*M aintainability will likely be the most important concer n since da ta pr ocessing softwa re tends to evolve. Reliability will also be of considera ble importance: Bill printing must be a ccura te, since it can be costly to r ectify mistakes. Usability of the bills themselves will be importa nt bec ause or dinary people have to understand them. Efficiency should not be a concer n.

THESE ANSWERS SUPPORT THE BOOK OBJECT ORIENTED SOFTWARE ENGINEERING:

PA3

PUBLIC ANSWERS TO EXERCISES

Chapter 2. Review of object orientation E2.1

p. 32 Distinguishing among classes and instances The class names in the following answers could var y slightly. The points in pa r entheses a re of lesser importance, and are for those who have r ead Chapter 5. a )*I nstance of AutomobileCompany. (or perha ps just Company) c)*Cla ss, subcla ss of Person. (In Chapters 5 and 6, we w ill see that it might be better to make this a subclass of PersonRole) e)*I nstance of Person.

E2.2

p. 33 Detecting bad class names and improving them a )*Bad. Is this a par ticular vehicle ( which might better be c alled something like Locomotive, or RollingStockConfiguration) or a scheduled r un (RegularlyScheduledRun) that could use a ny vehicle, or the run on a pa rticula r day (SpecificRun)? We will discuss this kind of problem in more detail in Chapter 6 in the context of the Abstraction Oc currence patter n. c)*Bad. The word ‘Data’ is inappropria te in a class name. Call it simply SleepingCar. e)*Bad. It should not be plural: Route would be better .

E2.3

p. 33 Naming different classes derived from words with multiple English meanings. a )*Title: Describes published books independently of the number of copies CopyOfTitle: or per ha ps LibraryItem: Represents physical books (as well a s other things, such as videos) that the librar y places on its shelves. c)*RegularlyScheduledFlight: has a flight number , depar ture time, or igin and destination a nd is flown every day; SpecificFlight: flies on a par ticular da y.

E2.4

pp. 34-35 Identifying attributes In this question a nd the next, there a re many alter na tives, a few possibilities a re shown her e. In pa rticula r sometimes cer tain attributes could be represented a s associations instead – these are shown in parentheses. a )*name, description, (producer, distributer) c)*date, startTime, endTime, description, soundAlarmWhenStarting, (room) e)*callerNumber, calledPartyNumber, isConnected, startTime, currentCell, signalStrength, totalCost

E2.5

p. 35 Identifying associations a )*boughtFrom:ProductionCompany, producedBy:Producer, episodes:Episode, leadActors:Actor c)* meetingRoom: MeetingRoom e)*caller:CallParty, called:CallParty

E2.6

p. 35 Differentiating between variables and objects a )*Object

E2.7

p. 36 Identifying operations In the following, opera tions that would proba bly be polymorphic a re shown in italics, however, exactly which opera tions are polymorphic would depend on the design. a )*getArea, getPerimeterLength, getPoints, move, resize, rotate, flipHorizontally, flipVertically

E2.8

p. 40 Identifying poor generalizations a )*Bad: You c a n’t say ‘A Cana dian dollars is a money’; a lso CanadianDollars should be an instance of Currency c)*Probably OK. e)*Bad: Account12876 would be instance of BankAccount (or some subclass of BankAccount)

E2.9

No public answer

© 2002 TIMOTHY C. LETHBRIDGE AND ROBERT LAGANIÈRE

PUBLIC ANSWERS TO EXERCISES

PA4

E2.10 pp. 41-42 Arranging potential classes into inheritance hierarchies (See also E5.21, p. 189) In the following, the hier ar chies ar e shown using indented text to save spac e. Whether it would be appr opria te to actually include all the classes in a given system would depend on the a pplica tion’s requirements. Ther e are many possible va riations on these a nswer s. Note: See also E5.21 for additional exer cises ba sed on these problems. a )*I n this pr oblem we c r ea te two separa te hier ar chies, Vehicle and PartOfVehicle. These could a lso have something like Machine as a common supercla ss, although the problem suggested crea ting separa te hiera r chies. 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 super cla sses of the vehicle lea f classes. c)*Schedule (We will learn later that this may not be needed since the whole system stores the schedule) RegularlyScheduledTrip (Added as a supercla ss representing something tha t runs at a given time) RegularlyScheduledExpressBus (rena med for clarity) BusRoute ActualTrip (Runs at a given time on a given day; could also be called ‘Run’) CharteredTrip (Renamed for clar ity) ScheduledTrip (Added to properly complement unscheduledTrip) UnscheduledTrip (Runs on a route, but not a t the normal time) BusVehicle (Renamed from ‘bus’ to distinguish different types of bus) LuxuryBus TourBus e)*Currency (Canadian Dollars and US Dollars ar e Instances) ExchangeRate (Attr ibutes or associations could be fromCurrency, toCurrency, r ate) FinancialInstitution (Added) Bank CreditUnion CreditCardCompany (Visa a nd MasterCar d 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

PUBLIC ANSWERS TO EXERCISES

E2.11 p. 47 Describing how polymorphic implementations of certain shape operations would work. a )*translate: In SimplePolygon (a s inher ited 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 r eturn height * width. I n RegularPolygon, it would compute the ar ea by dividing the polygon into numPoints individual triangles (see the a nswer to E2.30 for the detailed a lgorithm). Once this ar ea is calculated, the total ar ea of the RegularPolygon would be calculated by multiplying the a rea of ea ch 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 ma king this a subclass of ArbitraryPolygon, however that w ould be inappropria te since you don’t wa nt it to inherit methods such as addPoint and removePoint. A better solution is to make it a subclass of SimplePolygon. As a ttributes you would have to store the baseLength and height, or else you could store one of the two values for a ngles and the length of one of the sides, letting the other a ngle va lue a nd side be c omputed when needed. As methods, you would need changeScale, setBaseLength, setHeight, getArea, getPerimeterLength, getVertices, getBoundingRect, getBaseAngle, getTopAngle, a nd 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 ha s tur ned out to be par ticularly useful to ensure students r eally under stand the implications of polymorphism. Before assigning this exercise, it ha s pr oved to be necessary to explain the mater ial on pages 48 and 49 particularly ca r efully, with severa l exa mples. Note that the exercise has the assumption, “that the compiler knows that no new c lasses or methods ca n be added to the hiera rchy”; it is worth r eminding students that this is not generally true in Java (you c an a dd a subclass unless the cla ss is declared final, a nd you cannot declar e a non-leaf class to be final). a )*I nvoking getPerimeterLength on a Rectangle varia ble: No dyna mic binding is needed since Rectangle is a leaf class and so the va r iable c ould only ever contain an instance of that class. The loca l method in Rectangle would alwa ys be called. c)*I nvoking getBoundingRect on a Polygon va ria ble: Dyna mic 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 var iable at run time. E2.18 p. 51 Researching products that claim to be object-oriented to determine if they really are. The a nswer to this question will va r y over time, depending on wha t products are a vaila ble. E2.19 p. 53 Using documentation to look up library classes and thus better understand a program. This is a purely pra ctical exer cise. Its purpose is to encour age 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

© 2002 TIMOTHY C. LETHBRIDGE AND ROBERT LAGANIÈRE

PUBLIC ANSWERS TO EXERCISES

E2.25 No public answer E2.26 No public answer E2.27 E2.28 E2.29 E2.30 E2.31

No public answer No public answer No public answer. No public answer No public answer

THESE ANSWERS SUPPORT THE BOOK OBJECT ORIENTED SOFTWARE ENGINEERING:

PA6

PA7

PUBLIC ANSWERS TO EXERCISES

Chapter 3. Basing software development on reusable technology E3.1

p. 63 Researching resources on the Internet that discuss aspects of reuse. The a nswer to this question will va r y since web pages ar e continually being added, deleted and cha nged.

E3.2

p. 63 Analysing information about reuse. For discussion only.

E3.3

pp. 69-70 Determining the services that should be present in a framework. a )*Reservation framework. • Add an instance of whatever that can be r eserved (e.g. a book, a place on a flight, a sea t in a theatre) • Add a n instance of whatever the r eservation is made on behalf of ( e.g. a library patron, a pa ssenger, a theatr e-goer). • Make a reservation • Delete a reser vation

E3.4

p. 70 Determining differentiating features of framework-based applications, as well as its hooks and slots. a )*Reservation framework. • Differ entiating features: - The classes of objects that can be reser ved and their a ttributes, associa tions and other operations - The a ttributes of the r eservation itself, a nd perha ps subcla sses r epresenting different types of r eservation - The classes of objects that a reser vation can be made on behalf of - The user interfa ce - Rules rega r ding the reservation, such as who can ma ke one, whether the item can be reser ved, etc. • Hooks: - A function that would be called when a r eserva tion is complete (e.g. to send a n email) - An function to call when reser vations are ‘full’ that could be used, for example, to add a wa iting list, or to give some form of notification to the user. - A function called to load a reser vation from a databa se. - A function called to save a reser va tion. • Slots: - There ma y be no slots in this system.

E3.5

p. 70 Determining the range of applications that might benefit from a framework. a )*Reservation framework. • A librar y system, where you can reserve items that are a lrea dy checked out • Reservation of sea ts on any kind of transportation system • Reservation of entertainment tickets

E3.6

p. 70 Evaluating alternative approaches to designing a framework. a )*I f you star ted with a ver tical fr amework for a frequent flier progra m, you would ha ve a lot of f acilities a lrea dy developed, some of which would be quite specific to the fr equent flier doma in. The following gives some ideas of the services, slots a nd hooks that might be pr ovided; ma ny va riations on this answer a re possible. i. Services: • Maintena nce of frequent flier a ccounts to which points (miles) c a n be added a nd redeemed (i.e. a dding new accounts; deleting accounts) • Keeping of ba sic per sonal informa tion (na me, a ddress, points) a bout ea ch frequent flier, with methods to update this informa tion (which w ould ca ll the first hook below to a llow ma naging of a dditional informa tion) • Keeping of a log of flights to be used when pr oducing r eports (would a lso be capa ble of recor ding other transactions, e.g. points a wa r ded for r enting a ca r). • Methods to add, delete and quer y the number of points in the account.

© 2002 TIMOTHY C. LETHBRIDGE AND ROBERT LAGANIÈRE

PUBLIC ANSWERS TO EXERCISES

PA8

• Generic mec hanism, given two cities, that would ca lculate how many points w ould be required to fly between them for fr ee for a given user. This would be ca lled when customers a re doing queries, a nd a lso when a person actually books a free flight to determine how ma ny points to deduct. This would call the first slot below to do detailed calculations. • Generic mecha nism, given two cities, that would calculate how many points to credit to a pa rticula r frequent f lier who pa ys for a ticket. It would be called when the user is ma king quer ies, a nd a lso when a person a ctually takes a flight, in order to cr edit points. This would call the second slot below for deta iled calculations. • Generic mec hanism tha t runs every month, calling the slot (below) for pr oducing r eports, and the hooks (below) for deleting inactive accounts, and perha ps promoting users to differ ent cla sses. ii. Slots (code that must be provided) • A method to eva luate rules rega rding how ma ny points are required to fly cer tain routes for fr ee. • A method to eva luate rules r ega rding how many points ar e obta ined fr om flying cer ta in routes (might be specific to cer tain classes of fr equent flier, certain times, etc.) • A method to produce a for matted pr intout of a fr equent flier’s a ccount (ea ch a irline may wa nt to make these appea r stylistically differ ent from other airlines). Note that instead of creating a slot, this functionality could be left out of the fr amework entirely. • Note that the user interfa ce would ha ve to be provided, but would probably not actua lly a ppear a s slots in the basic system; the user inter fa ce would be a separa te subsystem that would simply ca ll the ser vices. iii. Hooks (places wher e optional a dd-ons can ea sily be plugged in) • Ability to mana ge additional types of informa tion a bout fr equent fliers ( e.g. wor k address, email,), beyond the ba sic minimum information. Different airlines might wa nt to keep different kinds of infor mation for use in mar keting etc. • Ability to have differ ent classes of users (e.g. prestige user s who have accumulated lar ge numbers of points) • Mecha nism to delete a ccounts after a c er tain time period with no activity (this might be a ctivated by the monthly run that prints reports) • Ability to a dd different kinds of points to be used for differ ent pur poses (e.g. some a ir lines, in a ddition to miles, a lso keep tr ack of a separa te count of miles flown in fir st class; such points might have differ ent rules, such as expiring af ter the end of a yea r). E3.7

p. 70 Evaluating whether or not one should first develop a framework when designing an application. a )* Ar guments in favour of developing a full frequent flier fra mework: • Developing the fr amework improves your overa ll design. Since you would have to build flexibility into the fra mewor k to allow it to be used by other s, you would benefit from that flexibility when you have to make cha nges yourself. • As a consequence of the a bove, you would expect maintenance costs to be reduced; you would also expect to be able to respond faster to market-dr iven requirements changes. • You might be able to sell your framework to others, or to provide frequent-flier services to other smaller a irlines. • Should two airlines using the same fra mewor k decide to wor k together in a n a lliance ( or to merge) their systems would be more compatible with each other, r educing costs.

E3.8

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 a r chitecture. The following a re some of the r easons why not: • People typically use word processors on laptop computer s or other machines that may not be co...


Similar Free PDFs