The Symbian OS (779886), страница 90
Текст из файла (страница 90)
Applications implement the abstractclasses of an object-based, MVC-style, event-based application modelwhich is defined partly by the operating system frameworks and partlyby the GUI implementation. In fact, the event model goes surprisinglydeeply into the system, all the way to the Window Server.Non-native applications, written in Java, Visual Basic, OPL or, morerecently, Python and even Ruby (these are currently the most mainstreamhigh-level languages available on Symbian OS), depend completely onthe graphical support of the GUI implementation on top of which theyare written. Except for low-level development work, for example systemprogramming, writing Symbian applications is inherently GUI-dependent.Symbian ships only non-production test application UIs for systemcomponents that require a UI for testing, configuration, and so on.
In a426ONE SIZE DOES NOT FIT ALL: THE RADICAL USER INTERFACE SOLUTIONfinal licensee product, licensee applications manipulate the componentsdirectly or provide the application-level user interface.16.10Future DirectionsFrom 2006, smartphones are shipping with the latest releases of boththe UIQ and S60 user interfaces, both of which introduce new featuresto support UI differentiation and specialization, aimed particularly atenabling phone vendors and operators to customize, extend, and brandphone UIs.
In both cases, the latest UIs depend on the Symbian OS v9platform.If these releases are indicative, increased flexibility and customizabilitycertainly seem to be the dominating trends for the future evolution ofphone UIs.UIQ 3UIQ 3 emphasizes personalization and configurability. It includes featuresthat offer extended flexibility and new opportunities for differentiation andspecialization by phone vendors and operators, as well as new opportunities for third parties to provide end-user-installable UI customizations. Inparticular, UIQ ‘themes’ bring the notion of the skinnable user interfaceto UIQ. Themes may be ready-made (in other words, supplied by UIQ orcreated or customized by the phone vendor or other UI integrator), usercustomizable, operator-specific or supplied by a third party, encouragingthe market for downloadable themes.Operator customization based on Operator Configuration Package(OCP) themes and skins allows the provision of preloaded content including applications, sounds, settings, fonts, icons, animations and so on, byvendors supplying UIQ phones to operators.
There is also support for overthe air (OTA) features, allowing operators to configure (and customize)phones remotely.Supporting these features is the notion of parameterizable UI properties, with support for multiple screen sizes, multiple portrait and landscapemodes, touch-screen and non-touch-screen modes, and various hard andsoft key combinations. The resulting UI configurations (for example,flip-open and flip-closed styles and pen and softkey styles for differentproduct families) are intended to help developers maintain applicationcompatibility across a range of different devices while enabling vendorsto create a wider variety of phone styles.S60 3rd EditionAgain, much of the focus of the S60 3rd Edition UI is on enablingcustomization, including vendor, operator, end-user and enterprise customization.
Increased flexibility is emphasized too, with UI scalabilityFUTURE DIRECTIONS427supporting a wide range of screen sizes, both portrait and landscapemodes, and ‘double-resolution’, that is, high-resolution displays.The most significant support for differentiation is the enabling of coreapplication extensions, allowing operators to extend the core applicationswith new features while retaining basic application compatibility withother S60 phones. The emphasis is on supporting integration of operatorspecific features and services, as well as service settings and operatorcustomized UI look and feel, to enable a high degree of sophisticatedoperator-specific branding to be provided by phone vendors using S60on their products.17System Evolution and Renewal17.1 IntroductionThis case study looks at the forces and pressures that have driven theevolution and renewal of Symbian OS, from the earliest days of the systemto the latest Symbian OS v9 releases.A critical issue for any software company is keeping a complex softwaresystem fit for purpose in a context of rapidly changing technology.
Todo so requires continuous evolution and continuous renewal. Evolutionand renewal are, therefore, among the strongest internal drivers forengineering and architectural change.Customers, on the other hand, are typically more interested in features.Balancing the competing pressures, for feature growth on the one handand internal renewal on the other, is an important part of the business.Preserving the freedom to invest in renewal against relentless featurepressure and deciding where to focus that investment are critical elementsof a successful system strategy.In reality, of course, the two things are not independent.
Renewalis just another way to talk about the prerequisites for future features.But, simplistically, while the costs of new features might be charged tocustomers, the costs of renewal are an overhead. Left at that, featurestend to win the competition for development resources.Symbian OS faces the particular challenges of the mobile telephonycontext, which are acute. The pace of evolution since mobile telephonybegan to take-off in the mid-1990s, and particularly since the secondboom around 2000, has been breathtaking. That period of a little under adecade is also the period during which Symbian OS has been licensed tophone vendors.
The increase in capabilities of Symbian OS v9 comparedwith the original release of Symbian OS is quite dramatic.Charles Davies is forthright about the need for continuous renewal.430SYSTEM EVOLUTION AND RENEWALCharles Davies:All of Symbian OS needs to be renewed over time and it’s a challenge towork out how to do that. In architectural terms, renewal is one of the biggestchallenges.In theory, five years or so from now, Symbian OS will be at theouter limit of its original intended design life of approximately 15 years(depending on when you start counting).
Of course, it is a fact of lifethat software systems commonly outlive their design lives by severalmultiples. Bits do not wear out. Software does not fall apart over time.But still, the changing requirements and changing context mean that, inpractice, system evolution is almost continuous. The likelihood is that, infive years time, most of the headline features of the operating system, andmany of its significant architectural features, will be ones that were notpresent in the original releases; many of them may not even be presenttoday.This is the magic of renewal (or the problem, depending on howclose you are to it). Unlike the products which are built on top ofsoftware systems, software design life is typically managed by forestallingobsolescence through continuous re-invention and evolution, rather thanby withdrawal and replacement of products (although that difference mayhave much to do with the less tangible nature of software compared withhardware).17.2Design LifetimeAll designed systems have a design lifetime and, for any manufacturedsystem, deciding what that lifetime should be is as much about economics as it is about technologies.
For example, the design lifetime isone determinant of cost because it determines quality requirements forcomponents. It is also a key variable in calculating return on investmentand other accounting metrics and is, therefore, a key variable in decidingthe business case for a system and it remains a factor in deciding howmuch to invest in maintenance.Software systems are no different. However, unlike other manufacturedsystems, they do not wear out. Maintenance is not driven by use of thesystem causing parts to become defective because of ‘wear and tear’, butby change.
Maintenance in a software context mostly means defect fixing.Typically, the defects to be fixed are either those introduced by earlier(internal) software changes, or those which are revealed by an (external)change in the way the system is deployed. Thus, software maintenanceis driven by change, whether adding new components to the system,DESIGN LIFETIME431removing components, or using the system in a new product, or becausesome other contextual change exposes previously ignored defects.A simplistic way to distinguish maintenance from renewal is to countchanges made to keep a system viable during its design lifetime asmaintenance and changes carried out to extend a system’s design lifetimeas renewal. It is because software systems do not wear out that renewal ispossible and attractive. But increasingly, what makes renewal necessary isthe rapid pace of technological change.
Maintenance, therefore, shadesinto renewal and is necessary not to extend system design life but toensure that a system actually survives for its design life and is not madeobsolete by technology changing more rapidly than predicted around itor by new, disruptive technologies appearing and changing the externalcontext to one in which the system cannot compete. Renewal becomesas much a matter of survival as of extending the design life.Deciding between maintenance and renewal is by no means alwayseasy. There is a critical balance between maintenance and renewal, andgetting the balance right can be a tough challenge for any organization;deciding when to maintain and when to renew requires foresight, a clearand well understood strategy, and a good understanding of the technologycontext.
In the short term, maintenance always looks attractive; renewalfrequently looks expensive.Determining the Design Lifetime of Symbian OSThere was never any doubt about the goals of the software project for theSeries 5 operating system. It remained as it began, focused very clearlyon the requirements of that very particular device. However, there wasalso a broader context.Geert Bollen:There was already explicit intent to create an operating system suitable formultiple mobile devices, with a design life of 10 to 15 years.
There waslong-term thinking and there was also a vision of having software licenseesthat included mobile-phone manufacturers.David Wood is equally clear about the long-term nature of the originalvision.David Wood:I think we said something akin to ‘The 16-bit system was designed for fiveyears and would last ten; EPOC32 was designed for ten years and would lastfor 20’. It is interesting that we have already been through ten years of history,and I think it’s going to be around a lot longer than even we foresaw.432SYSTEM EVOLUTION AND RENEWALEven perfect foresight would not be enough to secure a 15-year systemlifetime. There is no option about accepting the challenge of renewal.The need for renewal is a fact of life. David Wood argues that it hasbeen fundamental to the way Symbian OS has evolved right from thebeginning.David Wood:The fact is that we did redesign many things in the initial evolution of SymbianOS.
The UI is an important example of that, the fact that we went through threeseparate UI designs to get to the Eikon UI. And there were similar changes, notquite so large-scale, but other changes in the implementation of other aspectsof Symbian OS, even before it got launched.While you cannot guarantee longevity for a system, you can certainlydesign for it.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
