Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 7
Текст из файла (страница 7)
The secondpattern, Escalate Errors (see page 32), describes how you can ensure thatan error is resolved cleanly and in the most appropriate manner.FAIL FAST17Fail FastIntentImprove the maintainability and reliability of your software by callingPanic() to deal with programming errors as soon as they are detected.AKAProgramming by Contract [Meyer, 1992]ProblemContextDetecting faults in your software should be done as early as possibleduring the development process since it can be over 10 times cheaper todetect them in the early stages of development compared to finding themonce your product has shipped [Fagan, 1976].Summary• You want to reduce the number of defects in your software and soimprove the experience for the end user by, for example, avoidingloss of their privacy, corruption of their data, and security vulnerabilities.• You want to reduce the effort associated with debugging and fixingdefects.• You want to improve the maintainability of your software by makingit easier to add new features safely.DescriptionThe problem we’re focusing on here is how to detect faults in our softwaresince a common issue when developing software of any complexity isprogrammer error.
These mistakes manifest themselves as defects, someof which will be very apparent while developing a component; othersare much more subtle and therefore long-lived and insidious. Althoughthey are all faults, there is a key difference between defects found duringthe production of a system by its developers and those discovered by endusers of the software.Finding defects during the development of a system has significantlyless cost1 than when they are found after the system has been deployed.1 This cost is in both the engineering time to investigate and find the root cause of thedefect and in deploying the fix.
In addition, there is a less tangible cost associated withdamage to the reputation of the software vendor. If the error were to cause devices to bereturned to the manufacturer then the costs could run into millions of dollars.18ERROR-HANDLING STRATEGIESTherefore a lot of programming effort should go into producing code thatis functionally correct and as error free as possible; however, the effortrequired to reach perfection steadily increases.2 While simple, small,standalone programs can be debugged relatively trivially, discovering theroot cause of a defect in larger, more complex systems can prove verytime-intensive. The reason for this general trend is that there is a greaternumber of components in larger systems, with an exponentially greaterpossible number of interactions between them. This is one reason whysoftware engineers are encouraged to abstract, encapsulate and modularize their designs, since it reduces the number of these interactions (aspromoted by patterns such as Proxy and Façade as described in [Gammaet al., 1994]).The root cause for a defect can be hard to track down in any system:• It may be that the defect doesn’t occur in a development environmentand it is only out in the field where the issue is first discovered.
Thismay be for a number of reasons, such as race conditions caused byevent-driven programming or simply because there weren’t enoughtests written.• The design of the software may not be well understood by thedeveloper investigating a defect.• The more complex a system becomes, the more likely it is that thedefect symptom manifests itself in a ‘distant’ component in whichthere is no obvious connection between the observed issue and theroot cause of the defect.Such defects can have a significant maintenance cost associated withthem. Notably they will be found later in the software lifecycle and willtake longer to fix.For software based on Symbian OS, reducing the occurrence of faultsis especially important when compared to desktop (or even enterprise)systems. Issuing software updates (or patches) is a common practicefor desktop PCs that are permanently connected to the Internet, withlarge amounts of available storage and bandwidth.
Patching software ona mobile device is less widespread, more complex and can be moreexpensive due to data transmission costs. Reducing the need to issueincremental updates to correct defects is of great value. Less tangibly,there is also the user’s expectation of reliability. Given the current climate,end users are used to their PCs containing defects and the requirementfor anti-virus software, firewalls, and continual patching is accepted. ForSymbian OS though, devices are generally expected to work, out of thebox, and be always available.
To meet these expectations, removal ofdefects early in the development cycle is essential.2 en.wikipedia.org/wiki/DiminishingReturns .FAIL FAST19ExampleAn example of a complex software component would be a multiplexingprotocol. For such a component there are three different viewpoints fromwhich to observe its software requirements:• API calls from clients on top of the stack – these direct the protocol toperform tasks, such as who to connect to and to send or receive data.• Internal state – the constructs used by the software to satisfy APIrequests from clients while respecting the protocol specification forcommunicating with remote devices.• Protocol messages from a remote device – data and control packetssent as part of the communication protocol both to and from peers.An example of such a protocol is the Bluetooth Audio Video Distribution Transport protocol (AVDTP) which has a specified interface knownas the Generic Audio Video Distribution Profile (GAVDP).3A GAVDP client will have a number of requirements on the API.
Theserequirements will normally be mapped onto the features laid out in theGAVDP specification published by the Bluetooth Special Interest Group(SIG) which includes connecting to a remote device, discovering remoteaudio–video (AV) stream endpoints, determining the capabilities of anendpoint, as well as configuring and controlling a logical AV stream. Thisis in addition to the fundamental requirement of sending and receivingthe AV data associated with an AV stream.The protocol implementation must conform to the specification definedby the Bluetooth SIG and, as is often the case with protocol specifications,it is important to handle all the (sometimes vast numbers of) possible casesand interactions that are permitted by the specification.
The net result isthat a fairly complex state machine is required to manage valid requestsand responses from remote devices, while also robustly handling domainerrors (such as invalid transactions from defective or even maliciousdevices), system errors (such as failing to allocate enough memory), andfaults (such as typing errors in hard-coded constants).In addition, there is the logic to map the API and the protocol together.Although initially this may appear to be fairly straightforward, for anopen operating system this is rarely the case. There can be multiple,distinct GAVDP clients using the protocol to communicate with multipledevices, or even the same device.
The stack is required to co-ordinatethese requests and responses in a robust and efficient manner.We hope to have convinced you that the Symbian OS GAVDP/AVDTPprotocol implementation is a complex component of software. It is apparent that faults could occur locally in a number of places: from incorrect3 For more information see [Campbell et al., 2007, Chapter 4] and www.bluetooth.com/Bluetooth/Technology/Works .20ERROR-HANDLING STRATEGIESusage of the API by clients, from lower layers corrupting messages, andfrom mistakes in the complex logic used to manage the protocol.As with all software based on Symbian OS, it is paramount that there areminimal faults in the released component.
In this case, the consequencesof faults can be serious ranging from jitter in the AV stream preventingend users from enjoying the content to allowing DRM-protected data tobe sent to an unauthorized device.SolutionThe basic principle of this solution is to ’panic’ – terminate the currentthread of execution – as soon as an unexpected condition (i.e. a fault)arises, rather than using an inappropriate default or trying to ignore theevent and carrying on regardless.The reason for panicking is to prevent the thread from attempting todo anything more and allowing the symptoms of the fault to spread.
Inaddition, it provides a convenient debugging point at which a call stack,representing an execution snapshot, can be retrieved. In debug mode, apanic can trigger a breakpoint and allow you to enter your debugger.This pattern explicitly encodes design constraints in software andchecks that they are being met. This prevents the scope of a problemgrowing by restricting the issue to a single thread rather than risking theentire device. This could be considered as forming the foundation of afault-tolerant system.StructureThis pattern focuses on the concrete places within a software componentwhere you can add lines of code, known as assertions or, more colloquially, as asserts, where a check is performed that the design constraints foryour component are being met.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
