The Symbian OS (779886), страница 91
Текст из файла (страница 91)
Designing for longevity means designing for the unknownsto which your system will be subjected in the future. What that reallymeans is designing extensibly.The two prerequisites for extensibility are a good conceptual designand natural extension methods. The Symbian OS architecture is built onmultiple levels of extensibility. System services are provided by serversthat serialize access to system resources. To provide a new service, youjust create a new server. Most servers are themselves extensible, becausethey are implemented as frameworks. To extend a server, you just create anew plug-in.
Within the system there are multiple patterns of abstraction.Active objects, for example, abstract all events, so that applications onlyneed to know how to handle the events they care about, without worryingwhat their source was. Sockets abstract all communications bearers, sothat applications only need to know about the message types they wantto send, without worrying about message transport.These are all examples of extensible design and there are many others.David Wood tells a story to illustrate his point about the way extensibilityis designed into Symbian OS at a deep level.David Wood:Bluetooth only emerged as a technology in 1998, about the same time Symbianwas formed. So when we designed the system, Bluetooth didn’t exist. NowI’m not trying to diminish the efforts of Symbian engineers, but when we didwant to implement Bluetooth it wasn’t that hard. Of course there are manydevils in the details but architecturally it slotted in quite easily as just anotheractive object, just another event source.
In broad terms, it fitted easily into ourarchitecture; we had foreseen that need by designing to be future-proof.At one of the early developer conferences there were questions from thefloor during a talk on implementing Bluetooth on Symbian OS, asking, ‘HowDESIGN LIFETIME433did you manage to do this?’ When the answer was given, the question cameback again, ‘But surely it couldn’t have been as easy as that!’ And the answerwas, ‘Well, for us it’s just another active object.’ That was the phrase used:just another active object. Later on it turned out those questions were fromPalm engineers, from the operating system part of Palm, and clearly theyhad been struggling to squeeze Bluetooth into their system which hadn’tbeen sufficiently future-proof. In the end they managed, of course, and therecertainly is Bluetooth on Palm OS today, but it required much more effort Ithink than with Symbian OS. So I do think Symbian OS is future-proof, becausewe design our frameworks with extensibility in mind.‘Future-proof’ is a bold claim but it was certainly the goal of theearly design of Symbian OS and, in key respects, has demonstrably beenachieved.There is, perhaps inevitably, danger too in abstraction.
Too manylevels of abstraction can lead to code bloat and poor performance andalso to over-complex and unmaintainable code. The job of the componentdesigners and architects is to understand where extensibility is required,and to enable it appropriately, and where it is superfluous and constitutesover-design and over-engineering.High Impedance of ChangeTechnology moves fast and each technology generation seems to movefaster.
The founder of Netscape, Jim Clark formulated his ‘Internettime’ law to express that fact, the so-called law of constantly increasingacceleration which compels ‘technological products to be released fasterand faster’ [Lewis 1999].1However, systems, especially large and complex systems, evolveslowly. This is not just true of software.
It is as true of social organizations (from large bureaucracies to large crowds) as of whole species(evolution) as of particular technologies (fossil-fuel-powered systems).Thus the corollary of the speed of change of technology is the highimpedance of systems to change.Entrenched systems change most slowly, as if large-critical-masssystems are slowed by systemic inertia. Operating systems becomeentrenched when they achieve a certain level of market saturation. Thiskind of entrenchment and inertia may be the biggest threat to renewal.Two ideas which have become central to what Symbian does, and howit does it, reflect the interesting dynamic between the drive for changeand the drive for stability:1The limit is based, as he says, on the speed of light: ‘How fast light moves down afiber-optic cable.’434SYSTEM EVOLUTION AND RENEWAL• Platformization is what drives Symbian’s business and technologygoals, the goal of creating a software platform suitable for hostingend-user-centered services across a diverse range of phone hardware• The lead product concept is a key part of the way Symbian drivesprojects, so that each software iteration is closely coupled to anddriven by the requirements of a particular licensee product.Platformization requires stability.
Lead products, on the other hand,drive innovation and change. In part, this approach has crystallizednaturally, out of practice.Providing an open platform for third-party development and bringingit to the emerging world of mobile phones (and other pocketable deviceshighly centered on communications) was one of the early rationalesfor Symbian OS, and remains as much so now as then. To make thatstrategy support multiple licensee UIs (to enable licensee differentiation),an equally basic rationale, requires a high degree of commonality inthe system below the licensee UI variations (80:20 was the early rule ofthumb guideline: 80% of common APIs underlying 20% of UI-specificAPIs). The challenge of the strategy, therefore, is to avoid the platformfragmenting beneath the centrifugal effect of UI variation, to enable as faras possible a write-once–run-on-all-variants development model.
Somecustomization for UI variants will always be required, but the minimalgoal of common data engines beneath custom UIs is achievable so longas unnecessary fragmentation is avoided.The lead product approach has proven a successful way to capturenew requirements and drive the evolution of Symbian OS forward whilesupporting licensees in bringing a more or less continuous stream ofleading edge products successfully to market and, in particular, whilemaintaining the hard product deadlines required for manufacturing.All Symbian OS projects are tied to one or more particular leadproducts that define the basic critical feature set for a release, drivethe release schedule, and provide early validation and real products forfinal testing.
Once the lead product has shipped, licensees can considerthat OS release a proven platform for subsequent product variants. Ineffect, this simply rationalizes the early approach of working closelywith licensees on real products, but provides a framework for supportingmultiple simultaneous licensees taking a given new release.17.3Renewal in Symbian OSTypically, a renewal strategy aims to anticipate future feature requirementsand evolve the system to be a better platform for those features than theRENEWAL IN SYMBIAN OS435existing platform.
To a lesser extent it also aims to improve any areaswhere the platform is deficient for current features.Renewal permeates Symbian OS. Examples range from major systemwide changes, which include UI evolution, the introduction of thereal-time kernel, and platform security, to numerous small upgrades andupdates, for example to track standards evolution in supported technologies (including Bluetooth, SyncML, vCard and vCalendar). Between thetwo extremes are many examples of significant architectural enhancements, whether to evolve services such as telephony to support newnetwork technologies, to introduce new services or to replumb essentialsystem services.• The UI architecture evolved through multiple iterations to the earlyEikon UI and, thereafter, to Uikon plus licensee UI variants (forexample, S60, MOAP and UIQ), which are themselves continuouslyevolving.• The new kernel provided a complete generational change at the heartof the operating system.• Platform Security was a major architectural evolution with systemwide impacts and high external visibility.• Large-scale tools and system infrastructure changes include toolchainupgrades from Visual C++, to Codewarrior, to Carbide and ARM, toolsupdates driven by the move towards standard C++.• New services include the power-management and system-startupframeworks.There are numerous examples of small architectural changes relatedto the above major changes, including evolution of the IPC mechanism,a new client–server architecture, and the ECom plug-in framework architecture.
Other examples of significant architectural evolution include twogenerations of multimedia re-architecture, significant telephony evolutionto support new network technologies (CDMA and 3G) and a forthcomingnew communications architecture.There are also numerous examples of continuous architectural evolution driven by performance requirements and of extending existingservices as new technologies emerge, for example, flash filing systemsand USB support.The largest changes have been phased in over multiple releases, partlyto manage the risks to licensees of large-scale change and partly to try tomaintain an incremental approach to development and to maintain themodel of frequent releases.
(Symbian’s earliest releases were monolithicand the project management lessons were learned the hard way.)For example, the real-time kernel was introduced as an option forSymbian OS v8 and then became the standard kernel for Symbian OS436SYSTEM EVOLUTION AND RENEWALv9, enabling licensees to evaluate the new architecture and giving themflexibility in when to migrate.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
