In the lecture we discussed the differences between Checked and Unchecked Exceptions. Go through the following list of conditions and decide whether this information should be represented as Checked Exception, Unchecked Exception, or as regular element of the program flow (typically return values of type boolean or of an enumeration type). Give for each decision an argument (one sentence). In case your answer depends on a context, explain which context you are assuming.

1. File can not be opened because no file with the given file name is found at the specified location.
2. File can not be opened for write access because another user has locked it for write access.
3. The user decides that he doesn't want to save the content of the file that he just edited.
4. While saving the content of a large file the file system reports that it can't complete the write process.
5. The user wants to send a file via Bluetooth, but he turned of the Bluetooth capability previously.
6. A variable can't be read because of a memory malfunction.
7. The connection to a remote server is lost during communication.
8. The component that provides the basic user interface functionality can not be loaded.

After our discussion in Task 02 in the last assignment we decided to develop the component that allows to find Bike Rental Outlets nearby as a server component. The component gives a list of the 5 closest BROs if you pass the GPS coordinates as parameters. In the following you will discuss the availability of this component.

a) In the lecture we discussed two strategies to detect whether a component is available or not. Discuss which one is appropriate here. (2-4 sentences should be enough. Of course you can use as well the predefined format from the recent tasks.)

b) We mentioned the following tactics to handle failures. Discuss which one is appropriate here. (2-3 sentences per tactic should be enough. Of course the predefined format from the recent tasks could be especially helpful here as well.)

1. Client-sided switch to alternative component
2. Active Redundancy, Bridge
3. Active Redundancy, Voting
4. Handling failure of non-redundant components

Finally we describe one error handling strategy in detail.

Assume that due to cost restrictions

1. it will NOT be possible to have redundant components.
2. the server might be unavailable three days a month on average.

We decided to deploy a list of BROs by PLZ (Postal Code) on the mobile device. In case the mobile device is not able to get the list of closest BROs, it will offer to find the BRO by PLZ.

Draw a sequence diagram that illustrates the case of a failure and how it will be handled by the mobile device.

The sequence diagram should contain at least one or a few objects as part of the client, the stub representing the server object on the client, the server object, and one or more objects representing the middleware framework. (You might want to have a look at the slide 19 of chapter 8).

Write a program that demonstrates the advantages of the Composite design pattern. The program should create a tree of objects consisting of both composite and leaf nodes (demonstrating that the composite has correctly implemented a subset of the child management functions, such as addChild(), getChild(), and getParent()). Make sure that your tree consists of at least three levels, e.g. a root node with multiple children, where at least one of those nodes is a composite node with children. The program should then call an operation on the root of the tree. All composite objects should delegate the operation to their children while all leaf nodes should perform the action. Optionally the composite nodes can do something in response to the operation but they should then delegate the operation to their children.

Alternatively you may look for real world code that is accessible online and demonstrate the points using the example. (I.e. you submit a text with a description and links into the code.)

In the lecture we explained that we do not consider a good decision to let the class Stack be a subtype of List (or AbstractList). Repeat the argument and demonstrate the problem with a short program.

[We did not introduce JUnit tests in the lecture but you have illustrative examples in Assignment 0: Hello OOSC! and there is more information available on-line.]

You should implement some BRO classes and some JUnit tests demonstrating the behavior described in Task 03. Only the essential classes need to be close to a real implementation. You do not necessarily need to write UI classes. Your test may directly access the controller class(es). You may simulate external classes. E.g. you might want to have a class FakeMiddleware that you can set into a mode where it always fails or where it always succeeds. (Maybe it is even enough that it has just one boolean for that.)

In detail we would like to see classes as listed in Task 03 or similar plus test cases demonstrating:

• that the (Stub for the) Service of retrieving the nearest BRO might fail.
• that the software switches to using the local list in this exceptional case.