Overview of exercises in the book Object-Oriented Software Engineering: Practical Software Development using UML and Java
By Timothy C. Lethbridge and Robert Laganière
The exercises in the book cover many aspects of basic software engineering. They are designed to allow the reader to develop skills and understanding, building upon the raw knowledge contained in the book.
Instructor's manual: An instructor's manual for the book is available. This contains answers to most exercises, including full source code for exercises that require programming. To access the instructors' manual, instructors must contact the publisher to obtain the userid and password to the Lecturer's Centre of the McGraw-hill UK web site. Details about how to do this are located here.
Student's answer manual: To enable readers to work through the book on their own, a subset of the answers is available in a students' answer manual available here. In general, the public answers are for part a of multi-part questions. Questions for which such public answers are to be available are indicated in red in the list below, and also preceded by an asterisk.
Statistics about the exercises
The book contains:
- 169 Different types of exercises in the body of the chapters. These give practive
in most
of the key skills required of a beginner software engineer.
- 433 Specific questions of the above types (many types of exercises have parts a,
b c, d etc.). the answers to most of these are available in a 50+ page answer manyual
available to instructors. Contact your McGraw-Hill representatative. There is also a zip
file containing code for those exercise requiring programming.
- Many project exercises at the end of each chapter that give students a chance to deepen
their skills.
List of Exercises Types
Questions in red, and marked with an asterisk *, have public answers to part a, and in some cases parts c and e. Parts b, d, f and any other parts, as well as questions listed in ordinary black text, have answers only available in the instructors' manual (see above).
Chapter 1. Software and Software Engineering
* E1.1 p. 5 Classifying software.* E1.2 p. 10 Stakeholder reactions to situations.
* E1.3 p. 12 Prioritizing quality attributes
Chapter 2. Review of object orientation
* E2.1 p. 32 Distinguishing among classes and instances* E2.2 p. 33 Detecting bad class names and improving them
* E2.3 p. 33 Naming different classes derived from words with multiple English meanings.
* E2.4 pp. 34-35 Identifying attributes
* E2.5 p. 35 Identifying associations
* E2.6 p. 35 Differentiating between variables and objects
* E2.7 p. 36 Identifying operations
* E2.8 p. 40 Identifying poor generalizations
E2.9 p. 41 Analysing the consequence of making Quadrilateral & Rectangle subclasses of Polygon
* E2.10 pp. 41-42 Arranging potential classes into inheritance hierarchies (See also E5.21, p. 189)
* E2.11 p. 47 Describing how polymorphic implementations of certain shape operations would work.
* E2.13 p. 47 Incorporating new classes into an existing class hierarchy that contains considerable polymorphism.
E2.15 p. 47 Determining the methods needed to polymorphically implement an operation.
E2.16 p. 48 Determining immutable operations that may return instances of a different class.
* E2.17 p. 49 Determining when dynamic binding is needed in a set of polymorphic methods.
E2.19 p. 53 Using documentation to look up library classes and thus better understand a program.
E2.20 p. 53 Fixing an inconsistency in the Postal Code program.
E2.21 pp. 53-54 Designing modifications to the postal code program.
E2.22 p. 54 Implementing modifications to the postal code program.
E2.23 p. 54 Designing and implementing a new subclass in the existing Postal Code hierarchy.
E2.24 pp. 55-56 Evaluating and implementing design alternatives for the PointCP class hierarchy.
E2.25 p. 56 Tabulating the pros and cons of design alternatives.
E2.26 p. 56 Implementing an alternative design for the PointCP class hierarchy.
E2.27 p. 56 Conducting a performance analysis.
E2.28 p. 56 Improving the clarity of a design.
E2.29 p. 56 Designing, implementing and evaluating a design that makes use of interfaces.
E2.30 p. 59 Implementing a complete class hierarchy of shapes.
E2.31 pp. 59-60 Formal laboratory experiment: Conducting a performance analysis of Java classes.
Chapter 3. Basing software development on reusable technology
E3.1 p. 63 Researching resources on the Internet that discuss aspects of reuse.E3.2 p. 63 Analysing information about reuse.
* E3.3 pp. 69-70 Determining the services that should be present in a framework.
* E3.4 p. 70 Determining differentiating features of framework-based applications, as well as its hooks and slots.
* E3.5 p. 70 Determining the range of applications that might benefit from a framework.
* E3.6 p. 70 Evaluating alternative approaches to designing a framework.
* E3.7 p. 70 Evaluating whether or not one should first develop a framework when designing an application.
* E3.8 p.74 Evaluating whether an application should be designed as a client-server system or not.
* E3.9 p.74 Determining the services to be provided by a server.
* E3.10 p. 79 Evaluating the balance of work on the client and server side of a system.
* E3.11 p. 80 Writing protocols for a client-server system.
Chapter 4. Developing requirements
* E4.1 p. 106 Listing information to be consulted when performing a domain analysis.E4.2 p. 106 Writing a short domain analysis for a system.
* E4.3 p.110 Defining and narrowing the scope of a system.
* E4.4 p. 110 Giving precise problem statements, considering high-level goals.
* E4.5 p. 115 Describing functional requirements of a system.
* E4.6 p. 118 Classifying requirements into functional or non-functional.
* E4.7 p. 118 Rewriting requirements so they are verifiable.
* E4.9 p. 119 Writing non-functional requirements.
E4.11 p. 124 Practising brainstorming techniques.
E4.12 p. 126 Creating a list of actors for a mail-order company.
E4.13 p. 126 Creating a list of use-cases.
E4.14 p. 126 Creating a list of use-cases for the microwave oven system.
* E4.15 pp. 129-130 Describing the type of requirements document needed.
* E4.16 pp. 135-136 Finding problems in requirements statements.
* E4.17 p. 136 Rewriting requirements to remove defects.
E4.19 p. 141 Reviewing requirements for the GANA system.
E4.20 p. 146 Reviewing requirements for SimpleChat.
Chapter 5. Modelling with classes
E5.1 p. 160 Analysing an association and considering alternative multiplicities
* E5.2 p. 160 Designing associations among classes
* E5.3 p. 160 Explaining the consequences of associations in terms of creation and destruction of instances
* E5.4 p. 160 Reading associations in both directions.
* E5.5 p. 162 Adding association classes.
E5.7 p. 162 Transforming association classes and their associations to regular associations and classes.
E5.8 p. 167 Creating a class diagram with more than one generalization.
E5.9 p. 168 Drawing a class diagram corresponding to an instance diagram (See also E6.3, p. 208).
E5.10 p. 172 Distinguishing among ordinary associations, aggregations and compositions.
E5.11 p. 175 Writing constraints about shapes, and converting these to OCL.
* E5.12 p. 175-176 Writing OCL constraints.
* E5.13 p. 178 Designing how operations would be performed
* E5.14 p. 178 Writing OCL constraints for the genealogical example.
E5.16 p. 178 Evaluating a change to a class diagram.
E5.17 p. 179 Extending a class diagram to handle new requirements.
* E5.18 p. 184 Making a preliminary list of classes by listing noun phrases in requirements.
* E5.20 p. 189 Adding generalizations or interfaces to a class diagram.
* E5.21 p. 198 Additional exercises in drawing class diagrams, based on E2.10 (p. 41).
* E5.22 p. 192 Determining responsibilities for each class.
* E5.24 p. 194 Adding operations to a class diagram.
E5.26 p. 194-195 Extending the airline system to add new features.
E5.27 p. 196 Adding responsibilities and operations for new features of the airline system.
Chapter 6. Using design patterns
* E6.1 p. 206 Applying the Abstraction-Occurrence pattern.E6.2 p. 208 Representing a hierarchy of parts using the Composite pattern.
E6.3 p. 208 Ensuring that the General Hierarchy pattern is applied in E5.9 (p. 168).
E6.4 p. 215 Finding applications for the delegation pattern in the genealogical example.
* E6.5 p. 221-222 Determining the pattern(s) that would apply in specific design circumstances.
E6.7 p. 222 Writing a pattern representing the concept of a Cache.
E6.8 p. 224-225. Analysing designs to determine the extent to which a pattern applies.
E6.9 p. 225 Summarizing the advantages and disadvantages of the Observable layer of OCSF.
Chapter 7. Focusing on users and their tasks
E7.1 p. 232 Reflecting the usability and usefulness of everyday software.
* E7.2 p. 234 Determining the actors who will use systems.
* E7.3 p. 237 Writing use cases
* E7.4 p. 238 Drawing use case diagrams
* E7.5 p. 240-241 Writing use cases for the car park system.
* E7.7 p. 242 Listing use cases and prioritizing them.
* E7.8 p. 257 Creating error messages for a user interface.
E7.10 p. 257 Preparing a paper prototype.
E7.11 p. 257 Preparing a prototype UI for the GANA system.
E7.12 p. 258 Performing heuristic evaluations of user interfaces.
E7.13 p. 258 Performing a heuristic evaluations of a web site.
E7.14 p. 258 Having multiple people conduct separate heuristic evaluations.
E7.15 p. 259 Performing heuristic evaluation of a GANA prototype and updating the UI.
E7.16 p. 260 Performing an evaluation of a UI by observing users.
Chapter 8. Modelling interactions and behaviour
* E8.1 p. 273 Drawing sequence diagrams.E8.2 p. 275 Drawing collaboration diagrams.
* E8.3 p. 275 Drawing more collaboration diagrams.
* E8.5 p. 279 Determining the state the system would be in after a sequence of events.
E8.7 p. 280 Creating a state diagram for a traffic light.
E8.8 p. 280 Creating a state diagram for a four-way intersection.
E8.9 p. 280 Creating a state diagram for an intersection with turning signals.
E8.10 p. 280 Creating a state diagram for a vending machine.
E8.11 p. 283 Finding a missing transition in the automatic transmission state diagram.
E8.12 p. 283 Adding the Park control to an automatic transmission state diagram.
E8.13 p. 283 Learning about the history state.
* E8.14 p. 283-284 Drawing and extending state diagrams.
* P8.2 p. 291 Drawing state diagrams of OCSF and Simple Chat.
Chapter 9. Architecting and designing software
* E9.1 p. 299 Dividing a system into subsystems (see also E4.2, p. 110).E9.2 p. 304 Categorizing designs according to the types of cohesion they should exhibit.
E9.3 pp. 304-305 Determining flaws in designs with respect to cohesion.
E9.4 p. 305 Determining the kinds of cohesion present in the design of SimpleChat.
E9.5 p. 309 Evaluating Javašs reflection mechanism with respect to coupling.
* E9.6 p. 312 Categorising aspects of designs according to the coupling they exhibit.
* E9.7 p. 313 Determining ways to reduce coupling.
* E9.9 pp. 321-322 Choosing an architecture, basing the decision on quality requirements.
E9.11 p. 333 Studying architectures of peer-to-peer systems to determine how they can dispense with a server.
E9.12 p. 334 Studying the differences between CORBA and COM.
E9.13 p. 337 Designing a pipe-and-filter system to process stock quotations.
* E9.14 p. 339 Designing the architecture of systems.
Chapter 10. Testing and inspecting to ensure high quality
E10.1 pp. 348-349 Categorizing situations into failure, defect or error categories.
* E10.2 p. 353 Determining equivalence classes for testing purposes.
* E10.3 p. 355 Determining equivalence classes when there are multiple inputs.
* E10.4 p. 355 Determining boundary values.
* E10.6 p. 359-360 Tables of conditions for testing purposes.
* E10.8 pp. 365-366 Classifying and testing for numerical defects.
E10.10 p. 372 Testing for whether SimpleChat works sensibly when a resource is locked.
* E10.11 p. 372 Designing stress and unusual-situation tests.
* E10.12 p. 376 Writing test cases.
E10.14 p. 383 Planning for integration testing, including determining needed stubs and drivers.
E10.15 p. 387 Conducting code inspections.
Chapter 11. Managing the software process.
E11.1 p. 401 Reviewing group work in order to improve process.E11.2 p. 414 Finding sources of error in cost estimates.
E11.3 p. 415 Cost estimation for release 1 of GANA.
* E11.4 p. 419 Creating a team structure for different software projects.
E11.6 p. 422 PERT and Gantt charts for GANA Release 1.
E11.7 p. 422 Changes to cost estimate following production of PERT and Gantt charts
E11.8 p. 424 Improvement of process by applying project management techniques
Direct links to buy the book from
or
or a
wider list of bookstores.