Issott_Common Design Patterns for Symbian OS-The Foundations of Smartphone Software_0470516356 (779879), страница 4
Текст из файла (страница 4)
While some ofthe details of the operating system may well change, it is unlikely thatthere will be significant differences that impact the level of abstraction inwhich the patterns of this book are described.1.4 General Design PatternsThe genre of software design pattern books was established with thepublication of the ‘Gang of Four’ book [Gamma et al., 1994] in the 1990s.Since then a profusion of design pattern books have been published,including a small number explicitly for embedded systems, of which[Weir and Noble, 2000] is a good example.The aim of all of these books is to capture the collective experienceof skilled software engineers based on proven examples so as to helppromote good design practices. This is achieved through the creation ofGENERAL DESIGN PATTERNS3design patterns, commonly defined to be ‘solutions to a problem in acontext’.
The process of creating a design pattern reflects the way thatexperts, not just in software engineering but in many other domainsas well, solve problems. In most cases, an expert will draw on theirexperiences of solving a similar problem and reuse the same strategiesto resolve the problem at hand. Only rarely will a problem be solved inan entirely unique fashion. Design patterns are established by looking forcommon elements in the solutions to similar problems.The Introduction to [Gamma et al., 1994] and the Patterns chapter of[Buschmann et al., 1996] provide a good discussion of pattern theory sowe instead focus on how to get the best out of design patterns. Mostpeople start with a design problem that they’re not sure how to solveand so might start flipping through a design patterns book like this onelooking for inspiration.
Each of the patterns is written in such a waythat it should be as easy as possible to quickly understand whether it’sdescribing a solution to the problem you’re concerned with and whetherit’ll help you construct software with the properties you require. Onceyou’ve identified a pattern that looks like it should help, you should takesome time to customize it for your specific circumstances. Ideally, usinga pattern is comparable to approaching a problem as if you’ve solvedsomething similar in a previous project.
Then when you’re reviewing,implementing or documenting your software using a well-defined patterngives you a common vocabulary to help communicate to other engineersinvolved in the project how your software is designed.Here are some important things to keep in mind when using patterns:• All patterns have negative consequences in addition to the positivereasons that lead you to consider a given pattern in the first place.These negatives also need to be taken into account when choosingwhether or not to use a pattern.• You don’t get points for using as many patterns as possible whensolving a single problem. Patterns should only be used when they areactually needed.
The main reason for this is that using too many canresult in overly complicated solutions caused by the additional levelsof abstraction that they generally introduce.• Patterns are not intended to be used as fixed templates and applieddirectly to your software without thinking. Instead they should be usedas a guide to get you most of the way towards describing a workingsolution. It’s up to you to finish off the design process and ensure thatyour specific solution respects the details of your situation.Patterns are often very useful tools but only when applied to the rightjobs.4INTRODUCTION1.5 Symbian OS PatternsThat’s all very well but what’s this got to do with Symbian OS? Well, oneproblem with patterns is that, because they have been abstracted awayfrom specific problems, it can be hard to understand how best to applythem.
One of the goals of this book is to describe a set of patterns in moretangible terms specific to Symbian OS and so make them easier to applyin a Symbian OS context. This will be done via the following means:• Each pattern describes how the forces most relevant to an embeddedoperating system, such as Symbian OS, impact and are changed bythe patterns.• Explanations are given to explain how Symbian OS architecturalelements can be re-used in the application of the patterns.• Code samples are given in terms of Symbian OS APIs and codingstandards so that as much as possible of your job of translating apattern into practice has already been done for you.• Examples based on Symbian OS are given to show how the patternshave been realized in situations that Symbian OS developers canmore easily relate to.1.5.1 Constraints on Software Based on Symbian OSThe constraints on a mobile device platform means that software development for Symbian OS has to resolve a set of forces that are distinctfrom those found in desktop or enterprise environments.
Consider thefollowing list of constraints imposed by the mobile device environment:• Constrained hardwareCompared to mainstream laptops, mobile devices are between 10and 30 times smaller in terms of CPU speed, RAM size and storagespace and are set to remain so in relative terms even as they increasein absolute terms.
This is partly to do with the fact that mobiledevices are expected to be carried around in your pocket all thetime, putting both size and weight constraints on the devices. Anotherfactor is the fact that with over 7 million Symbian OS devices nowbeing sold each month,1 device manufacturers are keen to maximizetheir profits by keeping the cost of the materials in each device aslow as possible. Increasing the instructions processed per secondmeans including a faster CPU; boosting the memory available tothe system means including a bigger RAM chip. When shippingpotentially millions of each product, even small savings per deviceadd up quickly.
Also, if an end user finds that a device frequently runs1 www.symbian.com/news/pr/2008/pr20089781.html .SYMBIAN OS PATTERNS5out of resources, they can’t just plug in a new bit of hardware as theycan on a PC.• Limited power supplyUnlike fixed desktop computers or enterprise servers, mobile deviceshave to run from a battery. This limited power supply has to becarefully conserved so that the device can stay active for as long aspossible, especially because battery life is one of the top requirementsof end users. This constraint means that peripherals such as antennas,RAM chips, CPU, the screen, and so on, should all be used as little aspossible or used at a reduced rate to save power.• Expectations of high reliabilityEnd users expect and demand rock-solid stability and reliability fromtheir mobile devices; desktop levels of quality are not acceptable.One of the drivers for this is the fact that mobile devices can be alife-saving tool whether it’s to make an emergency phone call or toallow the rescue services to locate you if you’ve had an accident.
Anadditional factor is that it is relatively easy for an end user to switchbetween mobile devices; any devices that don’t measure up to thisstandard are returned to the manufacturer.• Open operating systemA key difference between Symbian OS and many other embeddeddevices is that the operating system allows the software on a deviceto be extended and upgraded after it has been shipped from thefactory and is in the hands of an end user. Hence, software cannot beoptimized for specific tasks or rely on events occurring in a set order.Software based on Symbian OS needs to be flexible, adaptable andallow for future changes.Note that whilst upgrades are possible on a mobile device, they’reusually restricted to functionality upgrades rather than providing defectfixes.
This is because getting the upgrade onto the device may welltake longer and may cost the user money if it is sent over the phonenetwork. Frequent updates would also increase the chance of mistakesoccurring and hence affect the reliability of the device unless carefullycontrolled.• Expectations of high securityAll of the stakeholders in mobile devices – users, device manufacturers, retail vendors, network operators, and suppliers ofsoftware, services, and content – expect them to be secure againstsoftware attacks. The risks include end users losing their private data,content producers having their DRM files stolen and damage to thereputation of device manufacturers.
The risks to mobile devices aresignificant because Symbian OS allows software to be installed: thereare multiple communication channels to and from the device, they6INTRODUCTIONoften contain lots of private information, and they support a number ofservices that can incur charges through operator tariffs, premium-ratemessages, and so on.• Restricted user interfaceDue to the small size of mobile devices not only are the screen sizessmall but they also suffer from minimal keyboards, if a keyboard ispresent at all, and other restricted human interface mechanisms.
Thismeans that user interfaces have to be made simpler. In addition, theyneed to be more adaptable than in larger devices because the enduser is more likely to make an error in interacting with the device.Note that this constraint mainly affects applications rather than theunderlying services.1.5.2 Important Forces in the Context of Symbian OSThe constraints listed in Section 1.5.1 lead to the following importantforces for software based on Symbian OS:• Minimal use of RAMRandom Access Memory (RAM) is a type of computer data storage.A key characteristic of RAM is that it is volatile and information itcontains is lost when a device is turned off.
The three main contributorsto RAM are:• Call stack – a dynamic data structure which stores informationabout the current execution including details of the active functionsand local data• Heap – an area of memory that you can dynamically allocate fromusing the new operator; ‘free store’ is another name for a heap• Code – devices that are not eXecute-In-Place (XIP) based load codefrom secondary storage into RAM where it is executed. Exactlyhow this is done depends on the memory model used but codecan make up a significant proportion of the RAM used on a device.The main motivation for reducing RAM is simply because there isa limited amount available on the device. However, a secondaryconsideration is that power is required to store data in RAM soreducing RAM can also result in less power usage.
On the other hand,minimizing RAM usage can be at the cost of increasing the executiontime if, for example, you reduce cache sizes.• Predictable RAM usageA necessary consequence of having limited RAM available is that atsome point it will run out. For some situations this can have catastrophic consequences for your device. For instance, if an end user istrying to call for an ambulance, the phone shouldn’t fail because theSYMBIAN OS PATTERNS7software couldn’t allocate enough memory. More commonly however, being able to predict memory usage means that your softwarecan prepare in advance and deal with the side-effects of allocatingRAM outside of the critical path.
This allows you to deal with anyerrors as well as the time needed for the allocations without disruptingyour main functionality. One trade-off that you’ll probably have tomake to improve this force is to use more RAM in situations whereyou over-predict the actual RAM usage.• Minimal use of secondary storageSecondary storage is where code, read-only data and persistent dataare stored. Most Symbian OS devices support secondary storage byproviding an area of flash memory2 though there exist some that havea hard disk drive.In all mobile devices, the amount of secondary storage is limited.You also need to remember that accessing it is much slower thanaccessing RAM. Another factor to consider is that secondary storagesuffers from wearing and degrades as it is used, though this is notoften a significant factor when writing software unless you’re a devicecreator.• Minimal execution timeThe execution time for a piece of software can have a number ofmeanings.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
